- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 26 Feb 2012 11:44:29 +1100
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: IETF-Discussion <ietf@ietf.org>, Julian Reschke <julian.reschke@gmx.de>, "Roy T. Fielding" <fielding@gbiv.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Tim Bray <tbray@textuality.com>, The IESG <iesg@ietf.org>, ietf-http-wg@w3.org
On 26/02/2012, at 11:40 AM, Stephen Farrell wrote: > > Mark, > > I was going to respond blow-by-blow but there's not much > point in that, other than to say that your mail seems to > me a tad over the top. Sorry if you think so. I'm VERY sensitive to the risks that we're undertaking here, and I want to be crystal-clear about what we're going to do. As I saw it, your path forward was a risky one. > (Maybe you misinterpreted me describing what might happen > as some kind of threat to try slow people down or something, > I don't know. I do know that I don't do that kind of thing > and if I tried I probably wouldn't be very good at it anyway;-) It may not have been your intent; my concern was that the effect would be the same. > Anyway, I think we should focus on a way forward that attempts > progress on what we appear to agree is the desirable outcome: > > > They are VERY VERY VERY interested in security, as are many other > > people in the broader community. If the IETF were to come up with a > > viable proposal that solves their problems, they would beat down this > > organisation's doors. > > I proposed a plan that I think might allow us to make progress > on that. I believe we could. OK, great. 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). Thanks, > > S > > > > On 02/25/2012 11:25 PM, Mark Nottingham wrote: >> >> On 26/02/2012, at 1:13 AM, Stephen Farrell wrote: >>>> >>>> If we just need a new authentication scheme, nothing stops people from >>>> working on that right now. >>> >>> I don't agree with you there - the perceived low probability that >>> something will be deployed is a real disincentive here. We have had >>> people wanting to do work on this and have been told there's no point >>> because it won't get adopted. >> >> Let's speak plainly here. >> >> It's not hard for new things to be deployed -- there are lots of new things being deployed on the Web right now. >> >> What IS hard is forcing browser vendors to deploy something that they don't think is going to work, or that they're not terribly interested in. >> >> They are VERY VERY VERY interested in security, as are many other people in the broader community. If the IETF were to come up with a viable proposal that solves their problems, they would beat down this organisation's doors. >> >> The IETF may have some smart people, and they may have ideas about Web security, but that doesn't necessarily make them into workable solutions for the various stakeholders. The discussion about Web security is much broader, involving not only the browser vendors, but also organisations like the W3C, IIW, etc. >> >> Using HTTP/2.0 as a mechanism to shortcut all of this and force what people in the IETF think is a good solution down implementers' throats is going to lead to a very predictable and messy fail. >> >> >>> With this plan if httpbis in fact select zero new proposals >>> that would represent a failure for all concerned. The "zero >>> or more" term is absolutely not intended to provide a way to >>> just punt on the question. >> >> This makes me very uncomfortable. How hard and long do we have to try before we convince you that we're not punting? >> >> >>> Such a failure at the point where httpbis was re-chartering >>> to work on a HTTP/2.0 selection with no better security than >>> we now have is probably better evaluated as a whole - I >>> guess the question for the IETF/IESG at that point would >>> be whether the Internet would be better with or without >>> such a beast, or better waiting a while until the security >>> thing did get fixed. >> >> >> If we "wait a while until the security thing [does] get fixed", I'll gladly bet any amount of money you care to name that SPDY will gain market traction so quickly as to make any HTTP/2.0 effort in IETF completely backwards-looking. Refer to the debacle with Cookies for one such example. >> >> So, again, I'm fine with allowing new authentication schemes to be proposed, in the off chance that some genius will suddenly propose something that meets all of the myriad requirements (that still aren't well-defined) and gets consensus and buy-in from implementers. >> >> However, requiring us to output such a beast and gating HTTP/2.0 on it is effectively asking us to spin our wheels for n years. And the folks working on SPDY will - quite rightly - walk away and do their work somewhere more sane. >> >> And I still don't see why it's necessary to do this all in one effort. Julian's point was that the only technical reason to combine authentication work with re-specifying HTTP is to make the new authentication scheme MTI. Otherwise, the work can be done separately. Roy has expressed interest in coming up with a new scheme that isn't necessarily targeted at browsers -- which is great, but I don't see why it has to be part of this WG. >> >> We potentially have a LOT of work on our plate, and that work is channeling the energy behind a new serialisation of HTTP into something worthy of being called HTTP. Doing research and development on Web security is a very different kind of work, and the two don't mix well, IME. >> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 26 February 2012 00:45:03 UTC