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

Re: Discussion of 9.2.2

From: Jason Greene <jason.greene@redhat.com>
Date: Sat, 27 Sep 2014 11:34:58 -0500
Cc: Michael Sweet <msweet@apple.com>, Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C098890D-66F9-488C-9B64-219CBA0188B7@redhat.com>
To: Willy Tarreau <w@1wt.eu>

On Sep 27, 2014, at 2: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).

It would break a large number of working H1-only clients just because the server the client is talking to also supports H2. The non-supported ciphers arenít all bad they just arenít state-of-art as of today.

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Saturday, 27 September 2014 16:35:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC