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

On Feb 23, 2012, at 5:23 PM, Paul Hoffman wrote:
> On Feb 23, 2012, at 5:13 PM, Roy T. Fielding wrote:
> 
>> I don't care how much risk it adds to the HTTP charter.  They are
>> all just meaningless deadlines anyway.  If we want HTTP to have
>> something other than Basic (1993) and Digest (1995) authentication,
>> then it had better be part of *this* charter so that the proposals
>> can address them.
> 
> 
> If only it were that simple. If the answer is "design an HTTP auth mechanism that is better than Digest", then this is a tractable goal. If it is "get IETF consensus on that auth mechanism", then it isn't. The latter has proven to be impossible because people say (possibly rightly) that web developers don't want auth mechanisms that use the browser chrome: they want auth in HTML, and anything that relies on the browser chrome is insufficient.

I don't need IETF consensus, just rough consensus and running code,
and I have no need to satisfy folks who think the Web is a browser.
The hard part is deploying anything that is incompatible with
already-deployed clients without letting them fall back to basic.

It is a trivial problem compared to choosing a new, non-MIME syntax.

What "web developers" want is based on what they can do today,
not what they can expect from an entirely new protocol.

> Notice how the topic changed from "HTTP" to "web" for the security discussion but not for the httpbis charter discussion? That topic-change has derailed the HTTP authentication discussions at recent (and not-so-recent) IETF meetings.


It didn't derail them.  They were not on any rails to begin with.

The problem with defining security in a separate group without
shipping implementations is that there is no need to compromise,
no need to identify and resolve specific use cases, and no need
to do something better than nothing.

If we add a requirement to HTTP/2.0 that user authentication MUST
be accomplished via a mechanism not subject to UI spoofing,
then that's what people will implement (if they implement at all).
The protocol can give the server all the control it wants over the
display of a background or separate window explaining what to do
in that other mechanism-not-subject-to-spoofing.  Give people just
enough rope to solve that problem without hanging themselves, and
the rest of HTTP (non-browser clients) can implement right now.

> If the charter has "develop HTTP authentication mechanisms beyond Digest", that's great: we already have seen about five proposals in the past few years for those, some of them with security analyses. If the charter says "...and specify one that is mandatory to implement", that seems prone to consensus failure because of religion about zero-knowledge proofs versus operational simplicity, but I would be overjoyed to be wrong about that.

I'd be happy with several imperfect mechanisms with differing
trade-offs that can be implemented in parallel.

....Roy

Received on Friday, 24 February 2012 02:21:39 UTC