Re: Discussion of 9.2.2

[Jason Greene <[e-mail]>]

On Sep 24, 2014, at 6:17 AM, Mark Nottingham <[e-mail]> wrote:

> We’re burning a lot of cycles on the TLS cipher suite requirements, and producing much heat but little light. Discussion seems to be looping, in part because people either aren’t reading the current spec language, or are drawing the wrong conclusions from it.
> 
> The actual requirements there are:
> 
> 1) HTTP/2 MUST only be used with cipher suites that have ephemeral key exchange [plus details].
> 2) HTTP MUST NOT be used with cipher suites that use stream or block ciphers.
> 3) Clients MAY advertise support of cipher suites that are prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2.
> 

AIUI, in order to meet these requirements without impairing usage of future ciphers, all TLS implementations must be updated to provide an API which:

1. Allows an H2 stack to set a strong preference for ephemeral key exchange OR anything stronger, and AEAD or anything stronger. The TLS stack then needs to ensure that all weaker algorithms are still selectable (for H1/legacy compat), but are below the priority list of ephemeral and stronger, and below AEAD and anything stronger. This specification can not use explicit cipher names, only characteristics.
2. Provides a post negotiation introspection API that allows an H2 stack to validate, that if ALPN selected H2, that a weaker cipher was not chosen. This also needs to be characteristic based, in such a way that stronger future characteristics do not fail the test.

In reality it will take some time for TLS APIs to get there, in particular if they are associated with another standards body, so HTTP2 implementations that are not willing to wait will then have to resort to some of the hacks suggested in the other thread. This likely means a number of H2 implementation in the wild overriding the available ciphers with exhaustive and correctly ordered whitelist, and then post validating the selected cipher is on the h2 portion of the whitelist. Any mistake made here results in interop issues. When the TLS stack is updated to include future ciphers, the H2 stacks won’t select them since that would require a code update, which might not be available. This is yet another interop failure potential if a site employees the strictest cipher requirements, and starts requiring ciphers more recent than a peer’s h2 implementation supports, yet its TLS stack would have.

After the industry adopts TLS 1.3, or even uses TLS 1.2 stacks with recent ciphers, the machinery (including the APIs) created to do this social hack ceases to add any value, but it can still continue to cause problems. Before this event occurs the value is very limited, as these old ciphers are still pervasive, since other more prevalent protocols, notably h1, will continue to operate with them.

If 9.2.2 is not dropped, an H2 implementation without access to the above API, is likely best off going the route Roy is taking and simply ignoring the provision. Interop problems will of course crop up, but at least they will be momentary, detectable, and solvable with administrative action.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat