RE: 9.2.2 Cipher fallback and FF<->Jetty interop problem

The HTTP/2 spec’s restrictions on the TLS versions and cipher suites creates a number of issues:
a) TLS code needs to filter ALPN IDs based on the negotiated TLS protocol version and cipher suite, or the HTTP stack needs to filter cipher suites and TLS protocol versions based on the enabled HTTP versions.
b) The server's security policy (e.g. allowed TLS protocol versions and cipher suites) is coupled to the supported HTTP versions. System admin cannot change these (seemingly orthogonal) things independently.
c) HTTP/2 spec needs to be updated when new secure cipher suites/TLS protocol versions are added, or currently available ones become compromised.

I understand the desire to use HTTP/2 as an opportunity to push the world to use more secure TLS versions and cipher suites, but creating interop issues for HTTP/2 users is not the best way to get there.

Cheers,

Andrei

From: Roland Zink [mailto:roland@zinks.de]
Sent: Wednesday, September 17, 2014 1:45 AM
To: ietf-http-wg@w3.org
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

So how are new ciphers added later? Does this require a new HTTP2 RFC, or a new TLS RFC or do they need to be registered with IANA? What if one of the now acceptable ciphers is no longer considered secure and should be disabled?

Doesn't this cipher selection belong into TLS and not h2?

Regards,
Roland


On 17.09.2014 07:44, Greg Wilkins wrote:
I have opened https://github.com/http2/http2-spec/issues/612 because this issue has not been resolved enough for me to understand enough to implement a working solution.
As well as my concern regarding the required capabilities of ALPN, I am struggling to work out how to implement 9.2.2 and I think there are going to be interoperability problems into the future. Specifically I think it will become impossible for a client to ever exclude a cipher from h2 acceptability without risking communication failure.
The basic problem occurs if ever the client and server disagree on exactly what is a h2 acceptable cipher.  The flow of the problem is:

  1.  Client offers connection with a set CLIENT_OK_CIPHER which is the union of CLIENT_OK_TLS_CIPHERS and CLIENT_OK_H2_CIPHERS
  2.  The server only sees the union set, so it does not know what ciphers the client think are h2 acceptable.  The server wants h2, so it picks a cipher from the intersection of CLIENT_OK_CIPHERS and SERVER_OK_H2_CIPHERS
  3.  If SERVER_OK_H2_CIPHERS != CLIENT_OK_H2_CIPHERS then a cipher may be picked that server thinks is h2 OK, but the client rejects because of it's interpretation of 9.2.2 at that time in the future.
  4.  The client and server fail to communicate even though they have ciphers and protocols in common!

The only way to avoid this problem is for the client and server to absolutely agree on what ciphers are h2 OK for all time and never ever ever EVER disagree.     This might be possible if 9.2.2 is rigorously written in a future proof way, but it is not:

   HTTP MUST NOT be used with cipher suites that
   use stream or block ciphers.     Authenticated Encryption with
   Additional Data (AEAD) modes, such as the Galois Counter
   Model (GCM) mode for AES [RFC5288] are acceptable.

So currently AES_128_CBC is an unacceptable h2 block cipher, but AES_128_GCM is accepted.   Do I hard code that AES_128_CBC is unacceptable or that AES_128_GCM is acceptable? If GCM is acceptable now, will GCM2 be acceptable in the future?  As written this clause does allow for future block ciphers with AEAD modes, but I don't know what they are in advance, so I can't hard code them?  Will there ever be acceptable block ciphers that use something other that AEAD?

Don't hard code I hear you say??? use a black/white list?????   Sure that allows both client and server to future proof their users interpretation of 9.2.2, but that is now just subjective configuration and there is absolutely no way that that client and servers will maintain the same h2 acceptable black/white lists.  If a client ever excludes a cipher from it's h2 acceptable set before a server has, then communication failure will result, even though client and server share acceptable ciphers and protocols!
In short, to avoid communication failure, the server either has to just use http/1 or it has to be absolutely sure it knows precisely what ciphers are h2 acceptable to the client.   I am unable to implement that kind of future proof telepathy and making it a configurable set just gives somebody else the impossible task of knowing what is client h2 acceptable.
regards

Received on Saturday, 20 September 2014 00:08:37 UTC