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

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.

 This leaves us with two things that can cause disagreement.

- We might introduce a new cipher suite.
- We might retroactively reclassify an old one.

In the former case, we should identify whether new cipher suites are
acceptable.
This could either be by making them match the characteristics in 9.2.2
(PFS + AEAD) or by explicitly saying they are OK. In either case, when
implementations add these cipher suites, they should know if they are
acceptable so you shouldn't have disagreement.

This leaves us with retroactive reclassification. We shouldn't do that.

So, can you explain to me how client and server can disagree?



> If I have access to the TLS implementation, the questions I need to ask it
> about the ciphers are not clear, as I doubt they have methods like
> isBlockCipherButNotOneSuchAsGCM(). (suggestion 3 - improve the language in
> 9.2.2 to be more precise).  Also i am querying the server TLS impl which
> may still differ from the client TLS impl.
>

FWIW, NSS does have this. Given a connection you do:

* SSL_GetChannelInfo() which returns a structure that contains the cipher
suite
identifier.

* SSL_GetCipherSuiteInfo() which returns an SSLCipherSuiteInfo:
http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslt.h#127

The MAC algorithm tells you whether it's of type AEAD:
http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslt.h#149

-Ekr