- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 1 Nov 2014 05:35:07 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
> On 27 Oct 2014, at 1:54 pm, Mark Nottingham <mnot@mnot.net> wrote: > > <https://github.com/http2/http2-spec/issues/612> > > Reviewing the discussion, I think it’s going to be difficult to declare consensus on 9.2.2 in its current form. And yet, I get the big bucks* from the IESG to do the difficult things. Winning a straw poll is not necessarily consensus in the IETF. > Talking through it with a few of the proponents, my proposal to close this issue is to remove 9.2.2 (i.e., the specific requirements on cipher suites), but leave 9.2.1 (the section on TLS features) as-is. Talking it through at length with our Area Director and other IETF leadership, this will not fly (at least that easily). The fundamental technical issue — publishing a protocol standard that allows cipher suites that we know to be insecure — has not been addressed. Patrick is absolutely right about this. The question at hand is what interoperability cost is involved in 9.2.2. If it is a cost paid by a few implementations who don’t have adequate APIs immediately at hand, that is emphatically *not* a technical issue. If it were a considerable interoperability cost to the whole community — i.e., it caused long-term problems across most or all deployments of the new protocol — it would be serious enough to warrant consideration. So far, this does not seem to be the case; a significant number of browser vendors have said that they will not fall back to HTTP/1.1 if they see servers that cause them to throw INADEQUATE_SECURITY, thereby isolating those servers that are not conformant (and giving them a *very* strong incentive to become conformant). Even if they were to retry, it would not be an interoperability issue; only a performance degradation for non-conformant servers. In other words, while 9.2.2 may retard deployment of the new protocol while some implementations are updated to support it, it does not seem to put the entire effort at risk of interoperability problems. The arguments that this is a process or layering issue are not valid; both have been refuted. While some may consider the handshake “fragile”, they’ll need to explain how — given the above context — it affects interoperability in a way that’s significant. So far, I haven’t seen an explanation of how the handshake raises such an issue. If you think you have one, please carefully explain it to us (even if you have before — and thank you for your patience) soon. Without more (and convincing) information, we don’t have adequate reason to remove 9.2.2 from the specification, and therefore I think that the resolution that gets us to consensus on #612 is Martin’s first pull request: https://github.com/http2/http2-spec/pull/615 Sorry for the back-and-forth; it’s important to get this right. Regards, * If I’m really lucky, Barry will buy me a drink in HNL. -- Mark Nottingham http://www.mnot.net/
Received on Friday, 31 October 2014 18:35:34 UTC