WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
109 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

The IESG
A modified charter has been submitted for the Hypertext Transfer
Protocol Bis (httpbis) working group in the Applications Area of the
IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list ([hidden email]) by Tuesday,
February 28, 2012.

Hypertext Transfer Protocol Bis (httpbis)
=========================================

Charter
Last Modified: 2012-02-09

Current Status: Active Working Group

Chair(s):
    Mark Nottingham  <[hidden email]>

Applications Area Director(s):
    Pete Resnick  <[hidden email]>
    Peter Saint-Andre  <[hidden email]>

Applications Area Advisor:
    Peter Saint-Andre  <[hidden email]>

Mailing Lists:
    General Discussion:[hidden email]
    To Subscribe:      [hidden email]
        In Body:       subscribe
    Archive:           http://lists.w3.org/Archives/Public/ietf-http-wg/

Description of Working Group
----------------------------

This Working Group is charged with maintaining and developing
the "core" specifications for HTTP.

The Working Group's specification deliverables are:
* A document (or set of documents) that is suitable to supersede RFC
 2616 (HTTP/1.1) and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document that specifies HTTP/2.0 an improved binding of HTTP's
 semantics to the underlying transport.

### HTTP/1.1

HTTP is one of the most successful and widely-used protocols on the
Internet today. However, its specification has several editorial issues.
Additionally, after years of implementation and extension, several
ambiguities have become evident, impairing interoperability and the
ability to easily implement and use HTTP.

The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries,
 ABNF)
* Fix editorial problems which have led to misunderstandings of the
 specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented
 and also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated
 mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for
 common applications

It will also incorporate the generic authentication framework from RFC
2617, without obsoleting or updating that specification's definition of
the Basic and Digest schemes.

Finally, it will incorporate relevant portions of RFC 2817 (in
particular, the CONNECT method and advice on the use of Upgrade), so
that that specification can be moved to Historic status.

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

### HTTP/2.0

There is emerging implementation experience and interest in a protocol
that retains the semantics of HTTP, without the legacy of HTTP/1.x
message framing and syntax, which have been identified as hampering
performance and encouraging misuse of the underlying transport.

As such, there is an opportunity to create a new major
(non-wire-compatible) version of HTTP.

To do this, the Working Group will solicit candidates for this work from
the community, to be submitted as Internet-Drafts. Expected focus areas
for candidates include:

* Significantly improved perceived performance in common use cases
 (e.g., browsers, mobile)
* More efficient use of network resources; in particular, reducing the
 need to use multiple TCP connections
* Ability to be deployed on today's Internet, using IPv4 and IPv6, in
 the presence of NATs
* Maintaining HTTP's ease of deployment
* Reflecting modern security requirements and practices

Although proposals are not required to meet all of these goals, it is
expected that the resulting work (if undertaken) will be chartered to
meet them (and therefore, selecting one that meets the majority of them
as a starting point is in everyone's interest).

The Working Group will then select a starting point for the new work
based upon the following criteria:

* Compatibility with HTTP/1.1 semantics; i.e., it must be possible to
 pass through a HTTP/1.1 message with reasonable fidelity
* Broad implementer interest (e.g., from Web browsers, "back-end"
 or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.)

Changes to the existing semantics of HTTP are out of scope in order to
preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
request chain. However, the resulting effort may define new semantics to
further the goals above, along with suitable extensibility mechanisms
for defining additional semantics.

If the Working Group forms consensus around a proposal to use as a
starting point, it is expected it will re-charter to begin work on that
document (or set of documents). The resulting work will be known as
"HTTP/2.0", unless the Working Group determines that this isn't suitable
(e.g., for interoperability).

Although work on this new version will begin in parallel with completion
of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work
until it is complete.

Goals and Milestones
---------------------

  Done        First HTTP/1.1 Revision Internet Draft

  Done        First HTTP Security Properties Internet Draft

  Feb 2012    Working Group Last Call for HTTP/1.1 Revision

  Feb 2012    Working Group Last Call for HTTP Security Properties

  Feb 2012    Call for Proposals for HTTP/2.0

  Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a
              Proposed Standard

  Apr 2012    Submit HTTP Security Properties to IESG for
              consideration as Informational RFC

  June 2012   Re-charter to work on HTTP/2.0

###


Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Stephen Farrell

Down below, for the proposed HTTP/2.0 work it says:

 > * Reflecting modern security requirements and practices

In some earlier discussion I asked what "modern" means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is meant, if anything.

In particular, I think it'd be good to try get better
(more usable, more secure etc.) HTTP authentication
defined as a built-in part of HTTP/2.0.

My initial take is that if we're not going to do this
for a major revision of the protocol, then when are we
going to do it? So I'd like to see that included.

The counter argument offered was that better HTTP
authentication is complex and probably hard to get right
and so would be better handled separately.

While that's not an unreasonable point, my counter-counter
argument is that it doesn't seem to have worked very well
so far.

It was also argued that this charter is scoped to just
allow for selection of an initial candidate for HTTP/2.0
and there'd be another re-charter to follow based on that
selected candidate, so that discussion of specific
security features would be better done after that when
there's a specific protocol on which to do work.

My worry about that is that in practice the main
security aspects of a putative HTTP/2.0 will be very
hard to change at that point, so I'd like to see it
discussed as part of this phase of the work.

What do others think?

Thanks,
Stephen.

PS: When I say "like" above, that's what I'd personally
like, not a position that I'm adopting as a security AD.
(Alhough that'd be a fairly predictable position I guess:-)


On 02/21/2012 06:10 PM, IESG Secretary wrote:

> A modified charter has been submitted for the Hypertext Transfer
> Protocol Bis (httpbis) working group in the Applications Area of the
> IETF.  The IESG has not made any determination as yet.  The modified
> charter is provided below for informational purposes only.  Please send
> your comments to the IESG mailing list ([hidden email]) by Tuesday,
> February 28, 2012.
>
> Hypertext Transfer Protocol Bis (httpbis)
> =========================================
>
> Charter
> Last Modified: 2012-02-09
>
> Current Status: Active Working Group
>
> Chair(s):
>      Mark Nottingham<[hidden email]>
>
> Applications Area Director(s):
>      Pete Resnick<[hidden email]>
>      Peter Saint-Andre<[hidden email]>
>
> Applications Area Advisor:
>      Peter Saint-Andre<[hidden email]>
>
> Mailing Lists:
>      General Discussion:[hidden email]
>      To Subscribe:      [hidden email]
>          In Body:       subscribe
>      Archive:           http://lists.w3.org/Archives/Public/ietf-http-wg/
>
> Description of Working Group
> ----------------------------
>
> This Working Group is charged with maintaining and developing
> the "core" specifications for HTTP.
>
> The Working Group's specification deliverables are:
> * A document (or set of documents) that is suitable to supersede RFC
>   2616 (HTTP/1.1) and move RFC 2817 to Historic status
> * A document cataloguing the security properties of HTTP/1.1
> * A document that specifies HTTP/2.0 an improved binding of HTTP's
>   semantics to the underlying transport.
>
> ### HTTP/1.1
>
> HTTP is one of the most successful and widely-used protocols on the
> Internet today. However, its specification has several editorial issues.
> Additionally, after years of implementation and extension, several
> ambiguities have become evident, impairing interoperability and the
> ability to easily implement and use HTTP.
>
> The working group will refine RFC2616 to:
> * Incorporate errata and updates (e.g., references, IANA registries,
>   ABNF)
> * Fix editorial problems which have led to misunderstandings of the
>   specification
> * Clarify conformance requirements
> * Remove known ambiguities where they affect interoperability
> * Clarify existing methods of extensibility
> * Remove or deprecate those features that are not widely implemented
>   and also unduly affect interoperability
> * Where necessary, add implementation advice
> * Document the security properties of HTTP and its associated
>   mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for
>   common applications
>
> It will also incorporate the generic authentication framework from RFC
> 2617, without obsoleting or updating that specification's definition of
> the Basic and Digest schemes.
>
> Finally, it will incorporate relevant portions of RFC 2817 (in
> particular, the CONNECT method and advice on the use of Upgrade), so
> that that specification can be moved to Historic status.
>
> In doing so, it should consider:
> * Implementer experience
> * Demonstrated use of HTTP
> * Impact on existing implementations and deployments
>
> ### HTTP/2.0
>
> There is emerging implementation experience and interest in a protocol
> that retains the semantics of HTTP, without the legacy of HTTP/1.x
> message framing and syntax, which have been identified as hampering
> performance and encouraging misuse of the underlying transport.
>
> As such, there is an opportunity to create a new major
> (non-wire-compatible) version of HTTP.
>
> To do this, the Working Group will solicit candidates for this work from
> the community, to be submitted as Internet-Drafts. Expected focus areas
> for candidates include:
>
> * Significantly improved perceived performance in common use cases
>   (e.g., browsers, mobile)
> * More efficient use of network resources; in particular, reducing the
>   need to use multiple TCP connections
> * Ability to be deployed on today's Internet, using IPv4 and IPv6, in
>   the presence of NATs
> * Maintaining HTTP's ease of deployment
> * Reflecting modern security requirements and practices
>
> Although proposals are not required to meet all of these goals, it is
> expected that the resulting work (if undertaken) will be chartered to
> meet them (and therefore, selecting one that meets the majority of them
> as a starting point is in everyone's interest).
>
> The Working Group will then select a starting point for the new work
> based upon the following criteria:
>
> * Compatibility with HTTP/1.1 semantics; i.e., it must be possible to
>   pass through a HTTP/1.1 message with reasonable fidelity
> * Broad implementer interest (e.g., from Web browsers, "back-end"
>   or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.)
>
> Changes to the existing semantics of HTTP are out of scope in order to
> preserve the meaning of messages that might cross a 1.1 -->  2.0 -->  1.1
> request chain. However, the resulting effort may define new semantics to
> further the goals above, along with suitable extensibility mechanisms
> for defining additional semantics.
>
> If the Working Group forms consensus around a proposal to use as a
> starting point, it is expected it will re-charter to begin work on that
> document (or set of documents). The resulting work will be known as
> "HTTP/2.0", unless the Working Group determines that this isn't suitable
> (e.g., for interoperability).
>
> Although work on this new version will begin in parallel with completion
> of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work
> until it is complete.
>
> Goals and Milestones
> ---------------------
>
>    Done        First HTTP/1.1 Revision Internet Draft
>
>    Done        First HTTP Security Properties Internet Draft
>
>    Feb 2012    Working Group Last Call for HTTP/1.1 Revision
>
>    Feb 2012    Working Group Last Call for HTTP Security Properties
>
>    Feb 2012    Call for Proposals for HTTP/2.0
>
>    Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a
>                Proposed Standard
>
>    Apr 2012    Submit HTTP Security Properties to IESG for
>                consideration as Informational RFC
>
>    June 2012   Re-charter to work on HTTP/2.0
>
> ###
>
> _______________________________________________
> IETF-Announce mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Julian Reschke
On 2012-02-21 19:26, Stephen Farrell wrote:

>
> Down below, for the proposed HTTP/2.0 work it says:
>
>  > * Reflecting modern security requirements and practices
>
> In some earlier discussion I asked what "modern" means
> there. It seems to mean at least working well with TLS,
> but I'm not sure what else is meant, if anything.
>
> In particular, I think it'd be good to try get better
> (more usable, more secure etc.) HTTP authentication
> defined as a built-in part of HTTP/2.0.
>
> My initial take is that if we're not going to do this
> for a major revision of the protocol, then when are we
> going to do it? So I'd like to see that included.
>
> The counter argument offered was that better HTTP
> authentication is complex and probably hard to get right
> and so would be better handled separately.

I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing authentication framework?

> ...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Stephen Farrell


On 02/21/2012 06:33 PM, Julian Reschke wrote:

> On 2012-02-21 19:26, Stephen Farrell wrote:
>>
>> Down below, for the proposed HTTP/2.0 work it says:
>>
>> > * Reflecting modern security requirements and practices
>>
>> In some earlier discussion I asked what "modern" means
>> there. It seems to mean at least working well with TLS,
>> but I'm not sure what else is meant, if anything.
>>
>> In particular, I think it'd be good to try get better
>> (more usable, more secure etc.) HTTP authentication
>> defined as a built-in part of HTTP/2.0.
>>
>> My initial take is that if we're not going to do this
>> for a major revision of the protocol, then when are we
>> going to do it? So I'd like to see that included.
>>
>> The counter argument offered was that better HTTP
>> authentication is complex and probably hard to get right
>> and so would be better handled separately.
>
> I believe this should be orthogonal to HTTP/2.0. Is there a specific
> thing that makes it impossible to use the existing authentication
> framework?

Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards compatibility
would be a requirement of course, or at least an issue to
be considered.

But the existing HTTP client authentication is also not
necessarily very useful, and there have been a number of
efforts to improve on that, none of which seem to have
gotten sufficient traction to get widely deployed/used.
Maybe HTTP/2.0 is a good time to try fix that.

S.


>
>> ...
>
> Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Julian Reschke
On 2012-02-21 19:37, Stephen Farrell wrote:

> ...
>> I believe this should be orthogonal to HTTP/2.0. Is there a specific
>> thing that makes it impossible to use the existing authentication
>> framework?
>
> Who knows? We don't have a protocol on the table yet. I
> would imagine that some level of backwards compatibility
> would be a requirement of course, or at least an issue to
> be considered.
>
> But the existing HTTP client authentication is also not
> necessarily very useful, and there have been a number of
> efforts to improve on that, none of which seem to have
> gotten sufficient traction to get widely deployed/used.
> Maybe HTTP/2.0 is a good time to try fix that.

Well, we have an existing authentication framework. It would be
interesting to find out what's missing from it.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Stephen Farrell

Hi Julian,

On 02/21/2012 06:50 PM, Julian Reschke wrote:

> On 2012-02-21 19:37, Stephen Farrell wrote:
>> ...
>>> I believe this should be orthogonal to HTTP/2.0. Is there a specific
>>> thing that makes it impossible to use the existing authentication
>>> framework?
>>
>> Who knows? We don't have a protocol on the table yet. I
>> would imagine that some level of backwards compatibility
>> would be a requirement of course, or at least an issue to
>> be considered.
>>
>> But the existing HTTP client authentication is also not
>> necessarily very useful, and there have been a number of
>> efforts to improve on that, none of which seem to have
>> gotten sufficient traction to get widely deployed/used.
>> Maybe HTTP/2.0 is a good time to try fix that.
>
> Well, we have an existing authentication framework. It would be
> interesting to find out what's missing from it.

Fair point.

I would wonder whether that framework could be used
as-is if HTTP/2.0 does do away "with the of HTTP/1.x
message framing and syntax" but I guess some equivalent
functionality could be defined in that case.

So as in my initial mail the 1st question here is, what
does "modern" mean in this draft charter? E.g. does it
mean "same as the current framework with different
bits" or something else? If so, what?

And then should it include adding some new options
or MTI auth schemes as part of HTTP/2.0 or even looking
at that? (I think it ought to include trying for that
personally, even if there is a higher-than-usual risk
of failure.)

S

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Robert Collins-3
In reply to this post by Julian Reschke
On Wed, Feb 22, 2012 at 7:50 AM, Julian Reschke <[hidden email]> wrote:

>
> Well, we have an existing authentication framework. It would be interesting
> to find out what's missing from it.

browser id, openid, and oauth are all authentication frameworks built
on top of HTTP rather than with HTTP; being able to implement some or
all of those at the protocol layer would be very nice.

As to whats involved, I don't have a short-list at hand, sorry :)

-Rob

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Barry Leiba-2
browser id, openid, and oauth are all authentication frameworks built
on top of HTTP

OAuth is an authorization framework, not an authentication one.  Please be careful to make the distinction.

What we're looking at here is the need for an HTTP authentication system that (for example) doesn't send reusable credentials, is less susceptible to spoofing attacks, and so on.

Barry 
Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Adrien de Croy
In reply to this post by Julian Reschke

Hi Julian,

On 02/21/2012 06:50 PM, Julian Reschke wrote:

> On 2012-02-21 19:37, Stephen Farrell wrote:
>> ...
>>> I believe this should be orthogonal to HTTP/2.0. Is there a specific
>>> thing that makes it impossible to use the existing authentication
>>> framework?
>>
>> Who knows? We don't have a protocol on the table yet. I
>> would imagine that some level of backwards compatibility
>> would be a requirement of course, or at least an issue to
>> be considered.
>>
>> But the existing HTTP client authentication is also not
>> necessarily very useful, and there have been a number of
>> efforts to improve on that, none of which seem to have
>> gotten sufficient traction to get widely deployed/used.
>> Maybe HTTP/2.0 is a good time to try fix that.
>
> Well, we have an existing authentication framework. It would be
> interesting to find out what's missing from it.

session support with login and logout would be good.  I know it's a can
of worms, with some serious security implications.

But this is why no websites use HTTP auth to speak of, which makes it
difficult to do integrated authentication.

Adrien

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Mark Nottingham-2
In reply to this post by Stephen Farrell

On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:

>
> Hi Julian,
>
> On 02/21/2012 06:50 PM, Julian Reschke wrote:
>> On 2012-02-21 19:37, Stephen Farrell wrote:
>>> ...
>>>> I believe this should be orthogonal to HTTP/2.0. Is there a specific
>>>> thing that makes it impossible to use the existing authentication
>>>> framework?
>>>
>>> Who knows? We don't have a protocol on the table yet. I
>>> would imagine that some level of backwards compatibility
>>> would be a requirement of course, or at least an issue to
>>> be considered.
>>>
>>> But the existing HTTP client authentication is also not
>>> necessarily very useful, and there have been a number of
>>> efforts to improve on that, none of which seem to have
>>> gotten sufficient traction to get widely deployed/used.
>>> Maybe HTTP/2.0 is a good time to try fix that.
>>
>> Well, we have an existing authentication framework. It would be
>> interesting to find out what's missing from it.
>
> Fair point.
>
> I would wonder whether that framework could be used
> as-is if HTTP/2.0 does do away "with the of HTTP/1.x
> message framing and syntax" but I guess some equivalent
> functionality could be defined in that case.

That shouldn't affect the framework at all. At most, you'd have to define how to re-serialise the current syntax if you don't have a way to "tunnel" it (since HTTP/1.1 passthrough is required).


> So as in my initial mail the 1st question here is, what
> does "modern" mean in this draft charter? E.g. does it
> mean "same as the current framework with different
> bits" or something else? If so, what?

As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.


> And then should it include adding some new options
> or MTI auth schemes as part of HTTP/2.0 or even looking
> at that? (I think it ought to include trying for that
> personally, even if there is a higher-than-usual risk
> of failure.)


Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.

Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.

Regards,


--
Mark Nottingham
http://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Tim Bray-3
[in-line]

On Tue, Feb 21, 2012 at 2:40 PM, Mark Nottingham <[hidden email]> wrote:
>> And then should it include adding some new options
>> or MTI auth schemes as part of HTTP/2.0 or even looking
>> at that? (I think it ought to include trying for that
>> personally, even if there is a higher-than-usual risk
>> of failure.)
>
>
> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.

+1

HTTP's ability to be equipped with security technology has been
adequate, and I haven't heard much argument that its semantics were
the big obstacle to newer/better security.  Preserving its semantics
means its successor should be equally adequate.

Mnot is *understating* the risk of loading up the charter with this stuff. -T

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Stephen Farrell
In reply to this post by Mark Nottingham-2


On 02/21/2012 10:40 PM, Mark Nottingham wrote:
>
> On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:
>

>> So as in my initial mail the 1st question here is, what
>> does "modern" mean in this draft charter? E.g. does it
>> mean "same as the current framework with different
>> bits" or something else? If so, what?
>
> As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.

Well, I think the phrase does need to be replaced
by something else all right.

I'm reluctant to omit mention of security entirely
of course and do want to know what's gonna be done
for authentication in a putative HTTP/2.0.

Like I said, I'm pretty skeptical that any significant
change to security properties will be achievable at
that next charter stage.

>> And then should it include adding some new options
>> or MTI auth schemes as part of HTTP/2.0 or even looking
>> at that? (I think it ought to include trying for that
>> personally, even if there is a higher-than-usual risk
>> of failure.)
>
>
> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.

Based on past experience the milestones for this will be
wildly optimistic and it'll really take five years so at
the end of 2017 we'll be right where we are in terms of
HTTP authentication for all of which time HTTP authentication
will be the "next thing" to do. (Ok, I'm exaggerating a
bit there.)

I think both experiences are valid.

> Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.

It is true that many sites don't use HTTP authentication
for UI reasons. I don't think it follows that doing nothing
is the right approach. (Well, one could argue to remove all
user authentication from HTTP I guess - is that one of the
proposals?)

Cheers,
S.



Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Robert Collins-3
In reply to this post by Barry Leiba-2
On Wed, Feb 22, 2012 at 11:36 AM, Barry Leiba <[hidden email]> wrote:
>> browser id, openid, and oauth are all authentication frameworks built
>> on top of HTTP
>
>
> OAuth is an authorization framework, not an authentication one.  Please be
> careful to make the distinction.

I call rubbish:

http://tools.ietf.org/html/rfc5849#section-1.1

And I quote: "   client
         An HTTP client (per [RFC2616]) capable of making OAuth-
         authenticated requests (Section 3).

   server
         An HTTP server (per [RFC2616]) capable of accepting OAuth-
         authenticated requests (Section 3)."

OAuth certainly *thinks* it provides *both* Authentication *and*
Authorization, and it uses the same header that Basic and Digest do -
Authorization.

> What we're looking at here is the need for an HTTP authentication system
> that (for example) doesn't send reusable credentials, is less susceptible to
> spoofing attacks, and so on.

Those are good things too, though orthogonal to my point, which is
that some of the most widely deployed authentication - yes,
authentication - systems used by web sites are not part of the HTTP
protocol spec. OpenID  and cookie based systems in general.

(Though OAuth is a pleasing exception in that it can and does
preferentially use the Authorization header).

-Rob

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Mark Nottingham-2
In reply to this post by Stephen Farrell
Stephen,

The approach we're advocating for this WG is to solicit well-formed proposals, select one and develop it.

If there isn't one for HTTP authentication, how are you advocating we proceed?

Regards,



On 22/02/2012, at 9:53 AM, Stephen Farrell wrote:

>
>
> On 02/21/2012 10:40 PM, Mark Nottingham wrote:
>>
>> On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:
>>
>
>>> So as in my initial mail the 1st question here is, what
>>> does "modern" mean in this draft charter? E.g. does it
>>> mean "same as the current framework with different
>>> bits" or something else? If so, what?
>>
>> As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.
>
> Well, I think the phrase does need to be replaced
> by something else all right.
>
> I'm reluctant to omit mention of security entirely
> of course and do want to know what's gonna be done
> for authentication in a putative HTTP/2.0.
>
> Like I said, I'm pretty skeptical that any significant
> change to security properties will be achievable at
> that next charter stage.
>
>>> And then should it include adding some new options
>>> or MTI auth schemes as part of HTTP/2.0 or even looking
>>> at that? (I think it ought to include trying for that
>>> personally, even if there is a higher-than-usual risk
>>> of failure.)
>>
>>
>> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.
>
> Based on past experience the milestones for this will be
> wildly optimistic and it'll really take five years so at
> the end of 2017 we'll be right where we are in terms of
> HTTP authentication for all of which time HTTP authentication
> will be the "next thing" to do. (Ok, I'm exaggerating a
> bit there.)
>
> I think both experiences are valid.
>
>> Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.
>
> It is true that many sites don't use HTTP authentication
> for UI reasons. I don't think it follows that doing nothing
> is the right approach. (Well, one could argue to remove all
> user authentication from HTTP I guess - is that one of the
> proposals?)
>
> Cheers,
> S.
>
>

--
Mark Nottingham
http://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Stephen Farrell


On 02/21/2012 10:55 PM, Mark Nottingham wrote:
> Stephen,
>
> The approach we're advocating for this WG is to solicit well-formed proposals, select one and develop it.
>
> If there isn't one for HTTP authentication, how are you advocating we proceed?

I'm not thinking now in terms of advocating a specific
proposal for how to proceed.

Right now, I'm interested in what others reviewing the
draft charter think about this topic. That's the point
of having this discussion in the open like this.

(So maybe I should shut up for a while:-)

S

>
> Regards,
>
>
>
> On 22/02/2012, at 9:53 AM, Stephen Farrell wrote:
>
>>
>>
>> On 02/21/2012 10:40 PM, Mark Nottingham wrote:
>>>
>>> On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:
>>>
>>
>>>> So as in my initial mail the 1st question here is, what
>>>> does "modern" mean in this draft charter? E.g. does it
>>>> mean "same as the current framework with different
>>>> bits" or something else? If so, what?
>>>
>>> As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.
>>
>> Well, I think the phrase does need to be replaced
>> by something else all right.
>>
>> I'm reluctant to omit mention of security entirely
>> of course and do want to know what's gonna be done
>> for authentication in a putative HTTP/2.0.
>>
>> Like I said, I'm pretty skeptical that any significant
>> change to security properties will be achievable at
>> that next charter stage.
>>
>>>> And then should it include adding some new options
>>>> or MTI auth schemes as part of HTTP/2.0 or even looking
>>>> at that? (I think it ought to include trying for that
>>>> personally, even if there is a higher-than-usual risk
>>>> of failure.)
>>>
>>>
>>> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.
>>
>> Based on past experience the milestones for this will be
>> wildly optimistic and it'll really take five years so at
>> the end of 2017 we'll be right where we are in terms of
>> HTTP authentication for all of which time HTTP authentication
>> will be the "next thing" to do. (Ok, I'm exaggerating a
>> bit there.)
>>
>> I think both experiences are valid.
>>
>>> Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.
>>
>> It is true that many sites don't use HTTP authentication
>> for UI reasons. I don't think it follows that doing nothing
>> is the right approach. (Well, one could argue to remove all
>> user authentication from HTTP I guess - is that one of the
>> proposals?)
>>
>> Cheers,
>> S.
>>
>>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Amos Jeffries-2
In reply to this post by Tim Bray-3
On 22.02.2012 11:46, Tim Bray wrote:

> [in-line]
>
> On Tue, Feb 21, 2012 at 2:40 PM, Mark Nottingham wrote:
>>> And then should it include adding some new options
>>> or MTI auth schemes as part of HTTP/2.0 or even looking
>>> at that? (I think it ought to include trying for that
>>> personally, even if there is a higher-than-usual risk
>>> of failure.)
>>
>>
>> Based on past experience, I think the risk is very high, and we
>> don't need to pile any more risk onto this particular project.
>
> +1
>
> HTTP's ability to be equipped with security technology has been
> adequate, and I haven't heard much argument that its semantics were
> the big obstacle to newer/better security.  Preserving its semantics
> means its successor should be equally adequate.
>
> Mnot is *understating* the risk of loading up the charter with this
> stuff. -T


+1.

I think the new security additions should be limited to making it clear
and ensuring that HTTP as a transport neither adds nor substracts
security to the overall system.
  HTTP over TLS or such has connection-level security/authentication as
inherited from that TLS.
  HTTP message authentication or such has per-message security for the
particular message.

We may have to consider new features or restrictions to ensure that TLS
level security is retained end-to-end or such. But fixing problems in
those other layers in a charter to re-design the middle HTTP layer seems
inappropriate.

AYJ

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Willy Tarreau-3
In reply to this post by Robert Collins-3
On Wed, Feb 22, 2012 at 11:53:27AM +1300, Robert Collins wrote:
(...)
> OAuth certainly *thinks* it provides *both* Authentication *and*
> Authorization, and it uses the same header that Basic and Digest do -
> Authorization.

I think that this simply shows a semantic mistake from the past, where
authentication and authorization were a bit conflated. Look at the HTTP
headers, you have the server send "www-authenticate", and the client
responds with "authorization" ! At least this is a point we should clarify
in the next version, because I know too many people who consider that
authenticated == authorized. And this is also one reason for http-based
auth not being *that* much deployed in the applications world since they
have to pretend an authentication failure (401) to report a lack of
authorization if/when they want to offer the client a chance to try other
credentials.

Regards,
Willy


Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

David Morris-4
In reply to this post by Barry Leiba-2


On Tue, 21 Feb 2012, Michael Richardson wrote:

>
> >>>>> "Barry" == Barry Leiba <[hidden email]> writes:
>     Barry> OAuth is an authorization framework, not an authentication
>     Barry> one.  Please be careful to make the distinction.
>
>     Barry> What we're looking at here is the need for an HTTP
>     Barry> authentication system that (for example) doesn't send
>     Barry> reusable credentials, is less susceptible to spoofing
>     Barry> attacks, and so on.
>
> and is implemented in HTTP, not in terms of HTML forms, yet has all the
> flexibility of the HTML form method?

And includes the ability for the user to logoff / the server reset the
login?

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Julian Reschke
In reply to this post by Willy Tarreau-3
On 2012-02-22 07:49, Willy Tarreau wrote:

> On Wed, Feb 22, 2012 at 11:53:27AM +1300, Robert Collins wrote:
> (...)
>> OAuth certainly *thinks* it provides *both* Authentication *and*
>> Authorization, and it uses the same header that Basic and Digest do -
>> Authorization.
>
> I think that this simply shows a semantic mistake from the past, where
> authentication and authorization were a bit conflated. Look at the HTTP
> headers, you have the server send "www-authenticate", and the client
> responds with "authorization" ! At least this is a point we should clarify
> in the next version, because I know too many people who consider that

We can clarify it in *this* version. Do you have a specific proposal for
Part 7?

> authenticated == authorized. And this is also one reason for http-based
> auth not being *that* much deployed in the applications world since they
> have to pretend an authentication failure (401) to report a lack of
> authorization if/when they want to offer the client a chance to try other
> credentials.

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#status.403>:

"7.4.4 403 Forbidden

The server understood the request, but refuses to authorize it.
Providing different user authentication credentials might be successful,
but any credentials that were provided in the request are insufficient.
The request SHOULD NOT be repeated with the same credentials.

If the request method was not HEAD and the server wishes to make public
why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the representation. If the server does not wish to
make this information available to the client, the status code 404 (Not
Found) MAY be used instead."

What's wrong with this status code? As far as I can tell, what's missing
is UI, not protocol elements.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Julian Reschke
In reply to this post by David Morris-4
On 2012-02-22 08:04, David Morris wrote:

>
>
> On Tue, 21 Feb 2012, Michael Richardson wrote:
>
>>
>>>>>>> "Barry" == Barry Leiba<[hidden email]>  writes:
>>      Barry>  OAuth is an authorization framework, not an authentication
>>      Barry>  one.  Please be careful to make the distinction.
>>
>>      Barry>  What we're looking at here is the need for an HTTP
>>      Barry>  authentication system that (for example) doesn't send
>>      Barry>  reusable credentials, is less susceptible to spoofing
>>      Barry>  attacks, and so on.
>>
>> and is implemented in HTTP, not in terms of HTML forms, yet has all the
>> flexibility of the HTML form method?
>
> And includes the ability for the user to logoff / the server reset the
> login?

Is that a protocol problem or a user agent problem?

-- > <http://lists.w3.org/Archives/Public/www-archive/2012Jan/0023.html>

Best regards, Julian

1234 ... 6