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

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

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