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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/09/2014 5:44 p.m., 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

I think this is where your problem is occuring.

Sending the union of cipher suites only works if fallback is permitted
in-band. Such as fallback between TLS versions; when TLSv1.3 prohibits
a cipher and TLSv1.2 permits it the client can offer and uses
whichever TLS version the server chosen cipher permits.

To meet the 9.2.2 criteria for sending ALPN "h2" the client must send
the intersection of those two sets, not the union.

Senders can only have a chance of successful communication when their
sent cipher suite will work with every permutation of ALPN signals
offered. ie it must omit the ALPN "h2" indicator in order to send the
union which includes h2-incompatible ciphers.

Logically this selection principle carries over as a general
rule-of-thumb for any other ALPN token which limits ciphers or
encryption properties. Or even other TLS extensions that limit cipher
suite.


> 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

Following the rule of thumb, all delivered choices are h2 compatible,
HTTP/1.1 compatible and compatible.

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

Following the rule of thumb, this cannot happen.

> 4. The client and server fail to communicate even though they have 
> ciphers and protocols in common!

Following the rule of thumb this can still happen, but only in the
form of client and server completely disagreeing on cipher suites.

h2 is nothing special in this regard. We see that happening anyway
when both ends are restrictied to incompatible SSL/TLS versions. Such
as old SSL-only clients trying to contact a locked down TLS/1.2-only
server.


IMO 9.2.2 is overly restrictive in naming ciphers and types. We should
just reference the TLS working groups BCP document "latest version"
and leave the campaign for better TLS use in the TLS WG. *They* are
the experts on TLS best-practice after all.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUGTFsAAoJELJo5wb/XPRjBtkH/RzvYktqQR8mIDzIHYNMAFh8
1LSI3T7wbjASlI8cppDRtkHTvW3LPeRaKNnAv3LazrOSVDoFeJ6V2lq9MuAuao1n
NhL0Cj8kAZlyXQDkfrsr343LydoFi/GgV6XMxX1UtjtU7ng4XWAaaJeQ8QekMPVP
WlKZnEeu/8mQWOEHvbvkUb9FUQeD9LrN3fL7uvpCG4Jel9Zw0DHfRtxHT+1Xbu7M
rJE9Dn1vToVNuIgGWm7miAES+WcOgAea357lHNz5o67xeIO9/xKN6VYGA07MmnLB
zJkiaVDoH2bRCPWZjhIG78mN5cp0Oo4Xn6UZIbiTIt/RHWiFDy7p+ObxXh+bGnY=
=hShp
-----END PGP SIGNATURE-----

Received on Wednesday, 17 September 2014 07:00:41 UTC