Re: Straw-man charter for http-bis

Chris Newman wrote:
> 
> Here's my take as AD on some of the interesting topics in this thread:
> 
> 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.

Agreed.

Q: if we found out that Digest can't be fixed for I18N without a minor 
incompatible change, would it make sense to define a "Digestbis" 
authentication scheme (assuming for a moment that server and UA 
developers would support it)?

> 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 

Q: RFC2616 doesn't define security at all (except for the hooks used by 
RFC2617). Are you saying that RFC2616 can't be advanced to Full Standard 
without fixes to RFC2617? I guess this translates to the question: is 
the reference to RFC2617 normative or informative... (just looking for 
clarification here).

> 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.  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. Regardless, I would very much like to see forward progress on 
> the HTTP security situation.

Agreed.

> 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.

Agreed. There will be some overlap people-wise, but IMHO that's not a 
problem.

Looking at RFC2617, there seem to be several areas that need work:

(1) The framework itself,

(2) Known issues with Basic and Digest (including I18N),

(3) New schemes.

Re (1): in practice, form based authentication is frequently used for 
the simple reason because people feel that the authentication related 
popups in browsers are insufficient/ugly/whatever. It would be really 
great if the people who are going to work on RFC2617bis co-operate with 
the W3C HTML working group on fixing this.

> 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.

Agreed.

Best regards, Julian