Re: Straw-man charter for http-bis

[Paul Hoffman <[e-mail]>]

At 3:42 PM -0700 6/6/07, Chris Newman wrote:
>1. HTTP Digest Authentication
>
>The SASL WG appears to have decided that SASL DIGEST-MD5 is not a 
>useful authentication mechanism for a number of technical reasons. 
>I would be uncomfortable having a WG spend a lot of time refining 
>the existing HTTP Digest mechanism based on that experience. 
>However, documenting the i18n behavior of deployed implementations 
>sounds like a sensible thing to do.

It seems weird to do significant clarification work on 2616 and 
basically ignore 2617, given the normative reference to the latter. A 
better option would be to do full clarifications in 2617, including a 
discussion of the not-clarifiable internationalization issues. One 
such clarification is a list of the problems of HTTP Digest in the 
modern world.

This probably should not take "a lot of time"; if it does, it means 
that the clarifications are all the more valuable. HTTP implementers 
who see a lot of work in 2616bis and nothing in 2617 will not 
necessarily come to the conclusion that the IETF wants; it would be 
better to have a 2617bis that says what we want to say.

>2. HTTP Security
>
>Phishing demonstrates that HTTP's present security mechanisms are 
>not adequate to meet some important requirements of the present 
>users of the protocol.  I would be uncomfortable moving HTTP from 
>Draft Standard to Standard given this situation.  It's likely that 
>new work on HTTP security mechanisms (as outlined by 
>draft-hartman-webauth-phishing) is necessary.  However, even with 
>the present security situation, I have no doubt that RFC 2616 is 
>widely useful and improving the technical clarity of the base 
>specification is good work that would benefit the Internet 
>community.  The minimum work necessary to make a draft standard 
>revision of the base specification complete would be to clearly 
>document the limitations of the presently deployed HTTP security 
>mechanisms and the fact they are not adequate for all situations.

Agree, but...

>Beyond that I consider it inappropriate to hold publication of a 
>useful revision hostage to new security engineering work.  That 
>opinion may not be shared by others on the IESG.

Knowing ahead of time whether or not the work of this proposed WG is 
likely to get smacked down at the end by the IESG would greatly 
affect the people working on HTTPbis.

>Regardless, I would very much like to see forward progress on the 
>HTTP security situation.

draft-hartman-webauth-phishing generated no significant follow-on 
discussion that I can see (I would be happy to be mistaken). There 
are little bits of discussion here and there, but no momentum. 
Without a strong push from the Apps area for this work, I suspect 
that it will not happen or, if it does happen in a limited fashion, 
the results will not be widely adopted in implementations.

>3. One vs. Two WGs
>
>I would support the formation of two separate WGs: HTTP and HTTP 
>security as the people who have appropriate expertise for those 
>efforts are not identical. Indeed I'd be uncomfortable with a single 
>WG that was both revising 2616 and designing new HTTP security 
>mechanisms as the latter may be helped by the attention of security 
>experts that likely have no interest in the former.

Fair enough.

>4. Specification Rewrite
>
>Because the IETF process gives quite a bit of control to the 
>document editor and design teams, our process allows an alternate 
>editor to produce a competing specification and ask for a WG 
>consensus call to adopt that competing specification.  This is 
>discussed in the following IESG Note:
>   <http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt>
>>From discussions here, I suspect it's unlikely an alternate 
>>specification would
>be adopted by the WG in this case, especially because it might drop 
>the target status from draft to proposed for the reasons Keith 
>mentioned.  However, this is an important mechanism the keep the 
>process open.

The status of the new document is *much* less important than its 
correctness and usability to HTTP implementers.