- From: Michael Sweet <msweet@apple.com>
- Date: Sat, 27 Sep 2014 16:34:15 -0400
- To: Willy Tarreau <w@1wt.eu>
- Cc: Eric Rescorla <ekr@rtfm.com>, Jason Greene <jason.greene@redhat.com>, Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Willy, > On Sep 27, 2014, at 3:39 AM, Willy Tarreau <w@1wt.eu> wrote: > > On Fri, Sep 26, 2014 at 09:13:23AM -0700, Michael Sweet wrote: >> Eric, >> >> If you have a multi-protocol client that opportunistically uses HTTP/2 (which >> will likely be the case for a very long time for any web browser at least), >> then you can't simply require TLS/1.2 or omit non-HTTP/2 cipher suites from >> negotiation because that will cause existing HTTP/1.1 (and SPDY) servers to >> stop working if they don't support the specific TLS/1.2 ciphers or cannot >> negotiate TLS/1.2 at all. > > I'm suddenly wondering about something : why is it that we have to support > different ciphers for H1 and H2 despite transporting the exact same contents ? > If some ciphers are not acceptable for H2, that makes me think they are at > risk for H1 as well, so shouldn't we say that if an agent wants to support > H1 as a fallback to H2 during a handshake, then it should only support the > ciphers that are compatible with both, even if this means the handshake > might fail on some old H1 servers (hence they'll have to retry with H1 only > and more ciphers). That would also probably speed up H2 adoption and clean up > of older ciphers. I suspect that someone deploying a H2 server will not want something that degrades the user experience of those using H1. So I don't think that it will speed up H2 adoption - quite the opposite, in fact. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Saturday, 27 September 2014 20:34:46 UTC