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.
Received on Thursday, 9 October 2014 05:32:22 UTC