Re: #612: 9.2.2 requirements

Am 31.10.2014 um 19:35 schrieb Mark Nottingham <mnot@mnot.net>:

>> 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. 
If this is the concern then the cipher suites are not defined in h2. The correct way of doing this would be to copy TLS 1.2, add the text from 9.2.2 and publish this as TLS 1.3. Otherwise you are proposing insecure cipher suites for a lot of use cases including HTTP/1.1.

> 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. 
> 
My concern is mostly about the future, e.g. how is it possible to add a new cipher and/or new protocols. Without a plan how this can be accomplished without causing interoperability issues the short time advantage of having 9.2.2 may just be a step into the wrong direction.

> 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.
If I assume the ciphers can be configured at servers then administrators may break conformance without knowing it. Some clients may still work if they do a fallback. Then interoperability issues may occur quite often.

> 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.
> 
Assuming a new cipher xyz is added in a revision to 9.2.2 and to TLS. Then the clients TLS library is updated and supports xyz. The server is updated to support xyz as well. The client now offers xyz and h2. The server selects h2 together with xyz. The clients h2 implementation doesn't know about xyz and rejects it, although it would accept it together with h1.

Now is it necessary to bump up the http2 version number and ALPN token if a new cipher xyz not matching the 9.2.2 requirements is added? Or is it so unlikely that this is of no concern?


> 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
> 
Regards,
Roland

Received on Saturday, 1 November 2014 11:31:35 UTC