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

[Andrei Popov <[e-mail]>]

> The TLS protocol versions is not a problem, at least in no-MITM
> environment: The application knows if it is trying TLS 1.2+ or not. And I really hope that there is no TLS stack retarded enough to fallback behind app's back.

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?

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

> The HTTP/2 spec itself only needs update if AES falls, whole ECC falls, RSA falls, or some new TLS version makes the specified MTI unusable.

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.

Cheers,

Andrei

-----Original Message-----
From: Ilari Liusvaara [mailto:[e-mail]] 
Sent: Saturday, September 20, 2014 9:41 AM
To: Andrei Popov
Cc: Roland Zink; [e-mail]
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On Sat, Sep 20, 2014 at 12:08:07AM +0000, Andrei Popov wrote:
> 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.

The TLS protocol versions is not a problem, at least in no-MITM
environment: The application knows if it is trying TLS 1.2+ or not. And I really hope that there is no TLS stack retarded enough to fallback behind app's back.

Also, the server knows if it supports TLS 1.2+ or not. And if client and server is TLS 1.2 capable, the negotiated version will be TLS 1.2.

However, things can go badly if there is some TLS MITM (some "security"
products apparently MITM TLS connections) in the middle (but still passes ALPN). Then the client and server assumptions turn badly wrong.

The cipher requirements do have the shortcomings you note.

The PFS requirement is in the middle. It is feasible to just disable all non-compliant ciphersuites globally (for server). And version skew is unlikely, because new general-purpose PFS key exchanges are extremely rare.

> c) HTTP/2 spec needs to be updated when new secure cipher suites/ TLS 
> protocol versions are added, or currently available ones become 
> compromised (and special-purpose ones must be specifically enabled).

The HTTP/2 spec itself only needs update if AES falls, whole ECC falls, RSA falls, or some new TLS version makes the specified MTI unusable.

New ciphers (even "XYZ" ones) or TLS 1.3 do not require update (but TLS 1.3 introduces a new failure mode: If client is TLS 1.2- capable, and server is TLS 1.3-only, things are going to fail.
But that failure would happen with any protocol).

However, there is significant risk of version skew between the application and TLS stack. This can lead to app making incorrect decisions regarding cipher acceptability, with nasty consequences.


-Ilari