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

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 (iesg@ietf.org) 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<mnot@mnot.net>
>
> Applications Area Director(s):
>      Pete Resnick<presnick@qualcomm.com>
>      Peter Saint-Andre<stpeter@stpeter.im>
>
> Applications Area Advisor:
>      Peter Saint-Andre<stpeter@stpeter.im>
>
> Mailing Lists:
>      General Discussion:ietf-http-wg@w3.org
>      To Subscribe:      ietf-http-wg-request@w3.org
>          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
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

Received on Tuesday, 21 February 2012 18:27:01 UTC