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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf