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

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

On 24/09/2014 7:02 p.m., Eric Rescorla wrote:
> On Tue, Sep 23, 2014 at 3:41 PM, Greg Wilkins <gregw@intalio.com>
> wrote:
> 
>> 
>> 
>> On 24 September 2014 06:17, Eric Rescorla <ekr@rtfm.com> wrote:
>> 
>>> 
>>> On Tue, Sep 23, 2014 at 11:36 AM, Greg Wilkins
>>> <gregw@intalio.com> wrote:
>>> 
>>>> 
>>>> If the answer to this is to make h2 clients not offer new
>>>> ciphers provided by their infrastructure until such time as
>>>> their h2 impl is updated,
>>>> 
>>> 
>>> I think that this is how h2 clients must behave in order to
>>> make the requirements in 9.2.2 work. Can we agree that if h2
>>> clients behave this way, that there is not an interop problem?
>>> 
>> 
>> We can definitely agree on this.   If the client does not offer a
>> cipher that it later rejects due to the protocol the server
>> selects, then we do not get this problem.
>> 
>> However, I'm not sure we can achieve that with any reasonable
>> extension of 9.2.2
>> 
>> Firstly there is the practical problem that a lot of non browser
>> clients are administered with black lists rather than white
>> lists.   So for example a java client that is run on a new JVM is
>> likely to have new ciphers.    So at the very least we need to
>> instil a cultural change to make such clients white list
>> instead.
>> 
>> But the bigger problem is that when offering a TLS connection,
>> the client may be offering it for h1, h2 and spdy.   Thus this
>> way out of the 9.2.2 interop problem will mean that clients will
>> not be able to take advantage of the latest greatest ciphers for
>> h1
>> 
> 
> [Removing the rest of your message since I'm just trying to focus 
> on the technical issue.]
> 
> I'm sorry, I'm not following this point.
> 
> Say that someone invents some new cipher suite, X. It's either 
> acceptable for h2 or it's not [0].

You are looking at this wrong. The variants are:

 known acceptible       - 9.2.2 works
 known unacceptible     - 9.2.2 rejects
 unknown acceptible     - 9.2.2 rejects!!
 unknown unacceptible   - 9.2.2 rejects



> The client then behaves as follows:
> 
> - If it is acceptable for h2, the client offers it, since
> everything is fine. - If it's not acceptable for h2, the client
> offers it, secure in the knowledge that a conformant server will
> (per 9.2.2) not negotiate it for h2.
> 
> As far as I can tell, either of these is fine. Do you disagree?
> 
> 
> The only case that seems problematic is if the client doesn't know
> if it's acceptable. This can only really happen in cases where the
> HTTP stack and the TLS stack have an arms length relationship,
> since otherwise the implementor can just read the spec and see
> whether it's acceptable or not. In that case, the client must do
> either one of two things:
> 
> - Not offer the cipher suite (with the result that it takes a long
> time for such clients to get access to the latest cipher suite.) -
> Offer it and proceed with h2 if it's negotiated (potentially in
> violation of 9.2.2).
> 
> Neither of these should lead to interop failure. What am I
> missing.

The third outcome:
  - Offer it and fail h2 when client rejects the unknown (in violation
of 9.2.2 because it was safe or future AEAD and should have been
accepted).

In regards to "the implementor can just read the spec and see whether
it's acceptable or not".


Put yourself in the other shoes, imagine you were implementing RFC
2616 and the equivalent of section 9.2.2 existed there. What ciphers
would we all be forced to use today?
 Thats right, mandatory SHA1, block and stream ciphers and no way to
move to AEAD-only. Possibly even mandatory SSL/2.0 support (ouch!).
After all whats good in 1999 must be good for the few years 2616 was
projected useful for.

It's an insane idea. Just as insane as 9.2.2 without a prescribed
upgrade to better things (as opposed to mandatory downgrade to 1.1
with "bad" security).


> 
> -Ekr
> 
> [0] I think it's fairly unlikely we would deliberately standardize
> a new cipher suite that didn't work for h2 at this point, but
> that's a side issue.

So all future ciphers are and ever shall be AEAD? no.

The point of those arguing against you here is that there is a very
real possibility that sometime within the projected lifetime of h2
there will be a non-AEAD cipher developed that is safe to use with h2.
We already have a GCM block cipher "exception" and h2 lifetime has
barely even begun.

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

iQEcBAEBAgAGBQJUInZRAAoJELJo5wb/XPRjoXYH/jeco7oaUsw2E+SFRdntav3L
ad1Wlmm6IabxE7+G/dZkGf4qsaIEyGiCaxnM3l0DyTkHtmhp1yaasnoX69swPKnJ
PiQpAW+WDL8zbmL+JdKsVoyY9cWZXOyzzYjQ2sgJylDxsUniD/E25ULZeUPM6vka
m/06fh8MYp29e6uq7RzZdZsOfCm8hhyUfl2ENzTe+PJzpDgVeOf79QbcgWI24GF7
NSa3BU+pU48Y1B+VwpK8jMhxQBzON9QV1SkdhAnrtoDoakn+D3PJHJlnTZ+sgrIq
C1nBnPWZ1gasyH22sbzQmBcBYn6ymyXQ2ygmG0JfoW0z5lIJ4Uj1PESD2nBrxDk=
=hgqz
-----END PGP SIGNATURE-----

Received on Wednesday, 24 September 2014 07:45:08 UTC