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

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

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

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.


Received on Saturday, 20 September 2014 16:41:19 UTC