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

[Simone Bordet <[e-mail]>]

Hi,

On Tue, Sep 23, 2014 at 2:23 PM, Eric Rescorla <[e-mail]> wrote:
> 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.

How can the client do that if it does not even know what is the
protocol that the server will choose ?
The ciphers that would need to be suppressed for h2 may not need to be
suppressed for h1.
Along the lines reported by Michael Sweet for iOS, I have doubts that
JDK/Android implementations of TLS will offer much in this area, and
if they do it will take years.

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

Can you expand on what you exactly mean here ?
The client has no idea what the server will choose so from the client
point of view everything is legal.
Had the server chosen Pn and Cn, everything would have worked fine, so
how can the client "don't do that" if the server chooses h2 ?

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz