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

On Wed, Sep 17, 2014 at 03:44:52PM +1000, Greg Wilkins wrote:
> 
> 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?

TLS currently divides ciphersuites into stream, block or AEAD.

This division comes from the way the ciphersuite is used in TLS. It doesn't
actually come from crypto primitives used (e.g. AES is considered to be block
cipher, but AES-GCM and AES-CCM ciphers in TLS are AEAD).

And because type determines how it is used, the TLS stack must know the type
of each ciphersuite it can negotiate. It can also be found on definitions
of ciphersuites (since those need to specify how to implement it).

However, in the future, there may be ciphersuite of some currently unknown
fourth type (i.e. not stream, block nor 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!

If TLS stack has a way to query properties of ciphersuites, that could be
used. Unfortunately, I don't think all widely used ones do.

And if either end does not query the TLS stack but instead uses a whitelist
and then TLS stack gets updated (best practice is to dynamically link it,
so it can be updated on its own!)... Ouch.

The current ciphersuites are not the problem. It is the future ones. E.g.
if something like Google's nonstandard Chacha20-Poly1305 gets added (IRTF
CFRG has working document on cipher, after that is sent to RFC editor,
expect request for adoption on document on using that with TLS). Type: AEAD.

Also, that cipher would not have "_CCM(_|$)" or "_GCM(_|$)" in its name (like
all current AEAD ciphers do).

Or if you want really nasty one, add something using the Chacha20 cipher from
SSH (it is different from previous). Type: ??? (it sure isn't AEAD, block nor
stream in TLS)!

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

There are more subtle failures. Like client offering a set of H2-compatible
and H2-incompatible ciphersuites and ALPNs of h2 and h1. And then the TLS
stack doesn't know of coupling between h2 and ciphersuites, and proceeds
to pick some H2-incompatible ciphersuite and ALPN h2. Boom.

And the client and server can't get away by just including H2-compatible
ciphersuites. That would cause enormous amount of failures with H1 servers.


-Ilari

Received on Wednesday, 17 September 2014 07:33:07 UTC