Re: Concluding discussion on #612 (9.2.2)

Eric,

Here is a variation of the previous PR:
https://github.com/http2/http2-spec/pull/627

I've reverted TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 to a MUST and switched
the connection retry case to only when a client does inadequate security on
a cipher it was offering
for h1 fallback.

So most connections will be 1 round trip for old and new servers.  There
will be 2 round trips IFF a client chooses to offer weak ciphers for h1
fallback and there is a difference with 9.2.2 interpretation.  A client can
avoid having to implement the retry if it chooses to never offer a cipher
that it will not accept for h2.

Then no matter what the future brings in terms of ciphers, if a client and
server share a cipher/protocol pair then they will be able to connect.
This allows us to be strict in 9.2.2 - with the knowledge that if
circumstances do force deployment of non 9.2.2 compliant ciphers, we do not
risk communication failure.

regards






On 9 October 2014 16:31, Greg Wilkins <gregw@intalio.com> wrote:

>
>
> On 9 October 2014 16:00, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>> 1. It is going to have a negative impact on performance on clients
>>> which offer H2.
>>>
>>
> The issue is that ALPN does not allow ciphers to be offered conditionally.
> Wanting to avoid a second round trip in order to support h1 with weak
> ciphers
> does not mean that ALPN support it.
>
> So either: 0) we don't restrict cipher differently for h1/h2; 1) we
> enhance
> ALPN to allow ciphers to be protocol dependent; or 3) we design a
> handshake
> that works with existing ALPN that is not fragile.
>
> This PR is a proposal for 3).   I would look at it as penalising servers
> that do
> not accept strong ciphers rather than as penalising clients that offer h2.
> But I'm open to other proposal to make the handshake robust?
>
>
>
>> if the client and the server disagree about which ciphers are
>> acceptable for H2 (and specifically if the server likes some cipher for
>> H2 that the client does not) then you get a successful TLS connection
>> but the H2 stack generates an error. At this point, the client could retry
>> if it wished.
>>
>
> That was my very first suggestion way way back at the start of this whole
> thread.
> It was unacceptable but I can't recall why.
>
> But that would work for me, so long as it was a MUST that any client
> offering
> weak ciphers for h1 compatibility would retry without h2 if one of those
> ciphers is
> accepted for h2.
>
> I'll prepare a PR for that as well.
>
> regards
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>



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