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

On 23.09.2014 10:30, Eric Rescorla wrote:
>
> On Mon, Sep 22, 2014 at 7:10 PM, Greg Wilkins <gregw@intalio.com 
> <mailto:gregw@intalio.com>> wrote:
>
>     Patrick,
>
>     The reality is that many h2 implementations will not have access
>     to their TLS layer in any meaningful way other than getting either
>     a list of available cipher names or the name of the selected
>     cipher.   It does not help us to deny that reality.
>
>     A server receives an array of ciphers from the client, let's say
>     they are well ordered so the h2 acceptable ones are at the front
>     and the unacceptable ones are at the end.  The server does not
>     know where in that list the browser has decided to make the break,
>     so I can't just mechanically remove the ciphers that my deployment
>     thinks are unacceptable and then select element [0].
>     (suggestion 1 - send separate cipher arrays for each protocol)
>
>     I have to re-evaluate each cipher myself to test if it is h2
>     acceptable and I have to do so in a way that will always produce
>     the same answers as the client used, else I fail to connect.
>     (suggestion 2 - define a retry mechanism without unacceptable
>     ciphers instead of just failing).
>
>     I may not have access to the local TLS implementation, so
>     generally at best all I have is the cipher name. Sure I can come
>     up with a regex that works mostly today, using the wikipedia list
>     of AEAD cipher names.   But such an implementation will not change
>     in lock step with the entire browser population, so connection
>     problems will result.  Even if I make the list configurable, then
>     that is still insufficient as if clients change their h2
>     acceptability list at different times, server configuration will
>     have a choice of not talking to a subset. .
>
>
> You've offered this argument a number of times, but I'm still not 
> understanding
> how this happens. We have an existing list of ciphers which we can divide
> along whether they are acceptable or not. I think the 9.2.2 language is
> actually pretty clear but maybe I'm just too close to it. In any case, we
> can certainly make it unambiguous even if that means listing every
> cipher suite that is currently acceptable. In either case, client and 
> server should
> agree for every existing cipher suite.
>
My attempt to explain the potential problem. There are two things 
negotiated by TLS. One is the upper layer protocol like HTTP1 / HTTP2 
and the other is the cipher. When the protocol specifies also a list of 
ciphers then these two decision are not independent.

For example the TLS library gets updated to support some new cipher Cn 
which it thinks is fine with h2. The client offers h1, h2 and some new 
protocol Pn and also a list of ciphers including Cn. The server only 
supports h1 and h2. Both together with Cn. Now the server selects Cn and 
h2. The client TLS layer is fine with this and gives it to the http2 
layer. The http2 layer fails the check as it isn't in its white list. So 
for TLS the connection succeeded but the client can't continue with h2.

Now say the API is a bit more elaborated and the TLS library client 
offer h1 with cipher set C1, h2 with C2 and Pn with C3. Only C1 and C3 
contain cipher Cn. The TLS client library does a union of the cipher 
sets and as Pn is the preferred protocol the Cn is up in the list of 
ciphers. The server choose h2 and Cn. Now again the client can't 
continue although it supports h2 and Cn. It even can't continue with h1 
as h2 was negotiated with ALPN.

If the client wants to be on the safe side then it can offer only the 
ciphers which are in all sets, but this set may be small or even empty. 
Especially this set may not include 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 when Pn doesn't like it. On the 
server side TLS can't know which ciphers the client supports with which 
protocol.

Regards,
Roland