Re: #612: 9.2.2 requirements

[replying to my own post as sleep has yielded an additional argument]

Normally we specify conformance requirements for interoperability, to enforce a particular semantic or property, or to ensure a minimum level of functionality. The current 9.2.2 text is making a mandate purely to enforce a TLS best practice, and in doing so is putting an undue burden on already complex implementations of TLS to make sweeping changes on both the client and server side that negatively affect interoperability while violating layering - the TLS stack now needs knowledge about the application protocol.

I am not a fan of making hard requirements on cipher suites. I know from experience that such requirements become out of date quickly, forcing otherwise unnecessary updates to specifications, and they do not allow developers or users to make different choices (valid or otherwise) without sacrificing conformance.

However, in this case it seems that some feel that the mandatory cipher suite in TLS/1.2 is inadequate, and that a specific set of cipher suites is now preferred (and MAY be a requirement in TLS/1.3). Therefore, the proper, RFC 2119, approach would be to require support for one or more cipher suites that are seen as providing adequate security - that ensures interoperability and that the two end points will be able to negotiate a "secure" connection without requiring layering violations or causing interoperability problems.

Sent from my iPad

> On Oct 31, 2014, at 8:09 PM, Michael Sweet <msweet@apple.com> wrote:
> 
> 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)
>