W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: security requirements (was: Updating RFC 2617 (HTTP Digest) to use UTF-8)

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Sat, 4 Nov 2006 10:47:53 -0800
Message-Id: <66A47A80-23F3-471F-9B52-0E610F5C461A@osafoundation.org>
Cc: Robert Sayre <sayrer@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
To: "Roy T. Fielding" <fielding@gbiv.com>

On Oct 17, 2006, at 7:30 PM, Roy T. Fielding wrote:

> On Oct 17, 2006, at 5:38 PM, Robert Sayre wrote:
>> Does anyone think mandatory-to-implement authentication schemes or
>> transport-layer security mechanisms will be helpful and realistic?
> Not without changing the HTTP version number, but I suppose that
> I shouldn't assume that is obvious.  HTTP/1.1 has already been
> deployed and I have no interest in declaring any of those
> implementations broken just because they failed to anticipate a
> not-yet-specified secure auth mechanism.  That ship has sailed.

Not only is that not obvious, I'm not sure it's true.  Publishing a  
new RFC is not a declaration that implementations of previous RFCs  
are broken.   Nobody expects functioning crystal balls.  Changing a  
version number is a choice that's subject to all kinds of  
consideration and judgement, rather than a choice that's subject to  
hard-and-fast rules. (Even if there were rules/guidelines in a given  
spec about when a version number should change, future protocol  
authors might find good reasons to violate those, and HTTP has little  
or no such guidelines.)

What's the utility of a version number in HTTP?  This is helpful as  
an explanation of the last change in number:
   "the proliferation of incompletely-implemented
    applications calling themselves "HTTP/1.0" has necessitated a
    protocol version change in order for two communicating applications
    to determine each other's true capabilities."

   " No change is made to the version
    number for the addition of message components which do not affect
    communication behavior or which only add to extensible field  

So I guess a decision that CLIENTS MUST support Basic and Digest in a  
new HTTP RFC, might be signalled by a minor version bump.  The  
version bump could signal that support along with a bundle of other  
capabilities if necessary.  The server can use that information to  
change its behavior and work better with that client.  My personal  
opinion on that is it's probably not of sufficient usefulness for the  
disruption it would cause -- unless the bundle overall were more than  
just auth improvements -- because servers can already send auth  
challenges prompting the client to use Digest if it can.  But if a WG  
were to decide it was worthwhile, then that would be fine and  

But a decision that SERVERS MUST support Basic and Digest -- well  
that doesn't need a version bump at all to work.  We already have a  
way for servers to advertise support insofar as that's necessary for  
those algorithms.

Received on Saturday, 4 November 2006 18:48:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:40 UTC