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

Hi Martin,

> 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.

How does this help? Basically, if the TLS layer does not filter ALPN IDs, or the HTTP layer does not filter TLS protocol versions/cipher suites/TLS extensions, then connections will sometimes fail with INADEQUATE_SECURITY errors? I don't think a general-purpose Web server can realistically go down this path.

> 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.

This is my point exactly:)

> 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.

I am in full agreement: it is hard to get the world to disable weak ciphers and old TLS versions. Right now addressing a new TLS vulnerability involves:
1. Updating TLS RFCs;
2. Patching TLS stacks;
3. Getting patched TLS stacks deployed. 

Requiring certain TLS versions and cipher suites in HTTP RFCs means that now we also need to:
4. Update HTTP RFCs when TLS vulnerabilities are discovered;
5. Patch HTTP stacks for TLS vulnerabilities;
6. Get patched HTTP stacks deployed.

So it seems that instead of keeping the problem encapsulated at the TLS layer and figuring out how to better solve it there, we're spreading it to the application layer. I think this would be counter-productive.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Tuesday, September 23, 2014 1:16 AM
To: Andrei Popov
Cc: Ilari Liusvaara; Roland Zink; ietf-http-wg@w3.org
Subject: 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 18:01:04 UTC