W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Discussion of 9.2.2

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>
Message-ID: <20140927073925.GH26372@1wt.eu>
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,
Received on Saturday, 27 September 2014 07:39:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:21 UTC