The HTTP/2 spec’s restrictions on the TLS versions and cipher suites creates a number of issues:
a) TLS code needs to filter ALPN IDs based on the negotiated TLS protocol version and cipher suite, or the HTTP stack needs to filter cipher suites and TLS protocol versions based on the enabled HTTP versions.
b) The server's security policy (e.g. allowed TLS protocol versions and cipher suites) is coupled to the supported HTTP versions. System admin cannot change these (seemingly orthogonal) things independently.
c) HTTP/2 spec needs to be updated when new secure cipher suites/TLS protocol versions are added, or currently available ones become compromised.
I understand the desire to use HTTP/2 as an opportunity to push the world to use more secure TLS versions and cipher suites, but creating interop issues for HTTP/2 users is not the best way to get there.
Cheers,
Andrei
From: Roland Zink [mailto:roland@zinks.de]
Sent: Wednesday, September 17, 2014 1:45 AM
To: ietf-http-wg@w3.org
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem
So how are new ciphers added later? Does this require a new HTTP2 RFC, or a new TLS RFC or do they need to be registered with IANA? What if one of the now acceptable ciphers is no longer considered secure and should be disabled?
Doesn't this cipher selection belong into TLS and not h2?
Regards,
Roland
On 17.09.2014 07:44, Greg Wilkins wrote:
I have opened Received on Saturday, 20 September 2014 00:08:37 UTC