Re: #612: 9.2.2 requirements

Brian,

> On Oct 31, 2014, at 7:11 PM, Brian Smith <brian@briansmith.org> wrote:
> 
> 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 

Sigh. No implementation exists to offer that feature set, and the ALPN negotiation doesn't have information on what a particular protocol needs. And worse, there are already multiple protocols that a browser might negotiate, with different cipher suite requirements!

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

We have limited deployment of implementations that use their own crypto toolkits, or that only support http/2 and its cipher suites. And a bunch of work in progress prototypes whose developers have been complaining about these requirements from day one because their own toolkits are not capable of supporting both http/1 and http/2 TLS requirements.
 
>> 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.

You do if you want to ship applications for a particular OS and support the OS supplied TLS policies.

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

The point is that they cannot support HTTP/2 today with these restrictions, not that we can't make arbitrary API to support an arbitrary and questionable line in the sand that has obvious interop issues with today's web. HTTP/1 will be around for a very long time yet, so intentionally adding barriers to HTTP/2 adoption seems short sighted. You're trying to mandate security in a way that causes interoperability problems, and conformance requirements are supposed to work the other way (I.e., improve interoperability)