On 02/26/2012 01:54 AM, Mark Nottingham wrote:
On 26/02/2012, at 12:32 PM, Stephen Farrell wrote:
Could you please explain why you think tying this effort to HTTP/2.0 is
necessary to achieve that? To me that's the critical bit, and I still haven't
seen the reasoning (perhaps I missed it).
That's a fair question that doesn't have a good and quick
answer, and some of the argument applies to the httpbis wg
and not to HTTP/2.0 per se.
Aha. If we can decouple the auth work from the HTTP/2.0 deliverable, I'm less
concerned -- although we're going to be quite busy.
For *this* re-charter, can we only solicit proposals for auth, and make the
decision about what/if we'll go ahead in the *next* re-charter?
I.e., I'd like to wait before we decide on both pieces (the wire protocol and
auth) before making commitments, or even plans. Part of the selection process
for the wire protocol is determining implementer interest, and gathering the
same information about the auth proposals will shed a lot more light on this
conversation, I think.
Right, that's pretty close to what I proposed.
Let's see if we hear supportive noises or howls of outrage or silence.
I think I'd suggest to keep the idea of chartering a sec wg to pick up
the pieces that httpbis doesn't want to progress, once that situation
becomes clear. All going well, that'd result in some experimental RFCs
that could be picked up with little effort should events warrant. But
that doesn't directly impact on httpbis I guess.
S.
Caveats: this is probably something that needs more bandwidth
than mail; most of the points below were already raised by
others on this thread (though I didn't go back through all
the mail yet) and this is not in any particular ordering.
That's OK - we'll be in Paris soon.
- We've not really improved this in over a decade. Its time.
Don't disagree.
- The community's appreciation of better security has
changed in that time as well so maybe its more tractable
now and we've more experience of real attacks.
- Improving security after the fact is not a good plan.
Of course.
- Thinking a separate security WG could provide an answer
that'd be adopted seems less likely to work to some. (It
does seem more likely to work for some others admittedly.)
Yes, there are arguments on both sides.
- A backwards-incompatible change (if needed) could be
done much more easily when changing HTTP. Its at least
time to explore the area with that possibility in mind..
Hmm. One of the core ideas we're moving forward with is that 2.0 is
semantically compatible with 1.x, even if it isn't syntactically.
- A scheme less susceptible to phishing that got deployed
could be very valuable. Its not ridiculous to think that
might require breaking backwards compatibility somehow.
Agreed, but I think that's much more about the browser UI than about the wire
protocol.
So, a bunch of things. Maybe none individually compelling.
But arguably taken together sufficiently convincing that
not attempting again to do something here would really be
inexcusable.
And yes, I do recognise that attempting to solve this does
add some risk. Most good things do.
Absolutely.
Cheers,
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf