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

On Tue, Sep 23, 2014 at 11:36 AM, Greg Wilkins <gregw@intalio.com> wrote:

>
>
> On 23 September 2014 18:30, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>> You've offered this argument a number of times,
>>
>
> sorry for this.
>
>
>> but I'm still not understanding
>> how this happens.
>>
>
> which is why I keep repeating my attempt to explain it
>

Thanks. I'll try to address your comments below.



>  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.
>>
>
> No they can't.  Let's say a server has kept up to date with the latest h2
> acceptable ciphers, as have the majority of browsers.       The server then
> sees a handshake with the new XYZ cipher in it.  Because of the poor
> handshake design, the server does not know if the client is offering XYZ as
> a h2 acceptable cipher or simply because it was added to the clients cipher
> list but the client has not yet been updated to know it is h2 acceptable -
> and thus will reject a h2 connection that uses it.
>
> 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? I agree that it remains an open question what the
impact on
new cipher adoption will be.

 -Ekr


then 9.2.2 will work in the opposite way to what is intended and will
> eventually discourage adoption of new ciphers as it will require updates to
> application protocols as well.
>



> If we are to do social engineering of the cipher selection, can we at
> least design a robust handshake.    Having clients hide information on the
> assumption the server will work it out is just not a robust protocol design.
>



> regards
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>