Re: Discussion of 9.2.2

[Michael Sweet <[e-mail]>]

> On Sep 25, 2014, at 9:10 AM, Greg Wilkins <[e-mail]> wrote:
> ...
> 	• Implementations that do not have direct access to the properties of a cipher will still probably resort to black/white listing of h2 acceptable ciphers.   It will be impossible to prevent such configuration breaking your rule d), however having such a configuration will at least reduce the barrier to introducing new ciphers...  So INADEQUATE_SECURITY can still occur if such configurations are over zealously updated in contradiction to 9.2.2

This is a serious concern.  SecureTransport does not provide a "properties" API and has no way to specify priority or preference for cipher suites.  So unless I want to limit myself to servers that support HTTP/2-compatible cipher suites (I can't realistically do this), I will need to simply hope that the server will do the right thing or close my client-side connection if it doesn't.

GNU TLS has a notion of priority strings [1], and could potentially support a HTTP2 priority string, but there doesn't appear to be any way to match things up to the 9.2.2 text without resorting to specifying a whitelist.  (at least there you can specify an explicit priority order for cipher suites).

OpenSSL has a similar notion of cipher strings [2], although I'm not certain that you could define a cipher string that matches 9.2.2 and allows future algorithms.

Microsoft's sChannel APIs *may* be able to specify priority (I'm just not sure reading the documentation), but there is definitely no way to pick cipher suites based on properties - you have to specify lists of cipher suites using constants that MS provides.

Based on other posts we know that Java and NSS have similar issues with cipher suite selection and priorities.

I understand the desire to set a higher bar for security, but I just don't see how it can be implemented today without causing problems as soon as a new version of TLS or a new cipher suite is deployed.  Requiring a HTTP/2 implementation to make decisions about TLS cipher suite selection puts TLS interoperability at risk by developers that lack the necessary background or infrastructure (i.e. APIs) to implement it correctly, and that will just hurt adoption and long term use of HTTP/2.

Require TLS 1.2, recommend TLS BCPs, but please don't try to define a profile that is restricted to a version of HTTP that uses the same ports and ostensibly is supposed to work along side older versions of the protocol.

[1] http://www.gnutls.org/manual/gnutls.html#Priority-Strings
[2] http://www.openssl.org/docs/apps/ciphers.html

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair