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

On Tue, Sep 23, 2014 at 4:02 AM, Roland Zink <roland@zinks.de> wrote:

>  On 23.09.2014 10:30, Eric Rescorla wrote:
>
>
> On Mon, Sep 22, 2014 at 7:10 PM, Greg Wilkins <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.
>

I see what you mean. I think clearly a conformant HTTP client is going to
need to configure
the TLS stack to suppress any ciphersuite it doesn't recognize.


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

Again, this seems like a "don't do that then" kind of situation.

-Ekr