Re: #612: 9.2.2 requirements

Mark,

> On Oct 31, 2014, at 2:35 PM, Mark Nottingham <mnot@mnot.net> wrote:
> ...
> 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. 

First, TLS does not provide a way to tie cipher suite selection to ALPN.  That makes it impossible for a client or server to restrict their ciphers without deciding ahead of time to first try only HTTP/2-compatible cipher suites and, when that fails, re-try a HTTP/1.x only connection.  I think that counts as a technical issue, and definitely a performance issue that will only hurt adoption of HTTP/2 or force UAs to try two connections in parallel to avoid the HTTP/1 penalty.

Second, you cannot dismiss the inadequate API issue.  Currently only OpenSSL and GNU TLS offer APIs to select cipher suites based on general capabilities, and even they are not sufficient to match all of 9.2.2's current restrictions.  For SSP on Windows and SecureTransport on iOS and OS X, you have to either hardcode a list of known cipher suite constants or try to write a blacklist by querying the supported cipher suites and removing those that are known not to be acceptable.  On top of that is a known bug in SecureTransport that prevents you from actually using the API to set the enabled cipher suites... :/  None of the common TLS libraries provide a way to ask what the security properties of a particular cipher suite are, so it is impossible to programmatically support 9.2.2 and support new cipher suites without a code change in the application layer.

> 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. 

There are already issues with the lack of ALPN support (that are slowly being addressed), and I (and others) have brought up the lack of support for restricting the allowed ciphers for HTTP/2, for which there is no technical solution (ALPN doesn't support it) aside from the server or client giving up on the connection after a successful TLS negotiation with the wrong cipher suite.

> 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.

The problem is worse - the client software may support HTTP/2 while the server only supports HTTP/1.  Since it is likely that the negotiated connection will not be for TLS/1.2, how can a client possibly limit its set of cipher suites to those that are compliant with 9.2.2?  And then the server that still has to support HTTP/1 clients and older versions of TLS also cannot limit its set of cipher suites.  And since NO TLS library seems to support the notion of cipher suite ordering (at least none are documented to), and since ALPN has no way to specify acceptable cipher suites for h2, we *will* have otherwise conforming implementations needing to send INADEQUATE_SECURITY because the underlying TLS libraries are unable to support the HTTP/2 restrictions AND still allow HTTP/1 traffic.

> ...
> The arguments that this is a process or layering issue are not valid; both have been refuted.

No, they haven't.  I've documented the issues that make deploying HTTP/2 along side HTTP/1 impossible, and nobody has refuted my findings (quite the opposite).

> 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.

See above.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 31 October 2014 22:10:39 UTC