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