Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On 20 September 2014 11:10, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> If a client offers TLS1.0 with h2 and http/1.1 ALPN IDs, a compliant server must not negotiate h2. So either the HTTP stack has to disable TLS<1.2 when h2 is enabled, or the TLS stack has to know to ignore h2 ALPN ID when the client offers TLS<1.2. Am I missing something?

The draft permits the TLS stack to complete the negotiation.  That's
why we defined an INADEQUATE_SECURITY error code: for cases where the
stack proceeds.

>> It is feasible to just disable all non-compliant ciphersuites globally (for server).
>
> Yes, it is technically feasible to disable the TLS versions and cipher suites prohibited by h2 when h2 is enabled. This may also be the right way to improve security: http/1.1 is not any more secure than h2 when used with old TLS versions and weak cipher suites. But doing so will cut off the customers who were previously able to connect with TLS 1.0 and RSA-CBC, so I doubt that most Web servers are ready to do this.

No one is asking anyone to do that.  I don't consider it feasible to
ask a browser or server maker to cut out what turns out to be a
non-trivial proportion of their userbase, as it inevitably ends up
being.

> Yes, any of these conditions and a variety of other conditions will require an HTTP/2 spec revision. E.g. once our perception of the security of certain ephemeral key lengths, AEAD mode, specific cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256), or P256 curve will change, HTTP/2 spec will need an update. Previously these types of considerations were handled (admittedly, less than perfectly) by TLS specs. Now the HTTP/2 spec will also have to track this, which seems like a step in the wrong direction.

I don't consider this to be a problem any more than it is a problem
today with HTTP/1.1.  Which is, of course, understating the magnitude
of the problems with moving off old versions of TLS or bad
ciphersuites.  These things might not have widespread exploits, but
the vulnerabilities are a little beyond theoretical and we still can't
shift them.

Received on Tuesday, 23 September 2014 08:16:17 UTC