- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 27 Sep 2014 09:39:25 +0200
- To: Michael Sweet <msweet@apple.com>
- 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>
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. Just my two cents, Willy
Received on Saturday, 27 September 2014 07:39:59 UTC