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/ _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
