Re: #612: 9.2.2 requirements

Michael Sweet <msweet@apple.com> wrote:

> First, TLS does not provide a way to tie cipher suite selection to ALPN.


Sure it does. It is easy to see how a TLS implementation could be designed
such that it associates every ALPN protocol with a different set of cipher
suites and then chooses a cipher suite based on that information, even
before, during, or after it decides which protocol to advertise with 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.
>

There are already implementations doing the thing that you call impossible,
so it is clearly not impossible.


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

Those are *all* implementation issues that can easily be fixed. Also, keep
in mind that the HTTP/2 implementation can choose to use a different TLS
stack that is more capable and/or easier to modify. In particular, you're
not forced to use SecureTransport or SSP. Also, I see no reason to think
that it is impossible to modify SecureTransport or SSP to have the
additional capabilities in a way that is backward-compatible and
non-disruptive to existing applications.

Cheers,
Brian