How to handle HTTP/2 negotiation failure WRT TLS

Some random blatthering of thoughts from discussions with other Chromium folk..

HTTP/2 Spec section: http://http2.github.io/http2-spec/#TLSUsage
includes text like:
"""
Implementations MUST negotiate ephemeral cipher suites (DHE or ECDHE)
with a minimum size of 2048 bits (DHE) or security level of 128 bits
(ECDHE). Clients MUST accept DHE sizes of up to 4096 bits.

An implementation that negotiates a TLS connection that does not meet
the requirements in this section, or any policy-based constraints,
SHOULD NOT negotiate HTTP/2. Removing HTTP/2 protocols from
consideration could result in the removal of all protocols from the
set of protocols offered by the client. This causes protocol
negotiation failure, as described in Section 3.2 of [TLSALPN].
"""

When we fail to negotiate, what should the user agent do? Fallback to
a new connection with HTTP/1.X? Or hard fail?

There's a concern that a fallback is a vector for downgrade attack.
This of course assumes that HTTP/2 provides enhanced security
properties. A superior padding mechanism in HTTP/2 in comparison to
HTTP/1.X could be considered as providing HTTP/2 with enhanced
security in comparison to HTTP/1.X. So, a failure to negotiate HTTP/2
due to insufficient security parameters in TLS could result in the
same insufficient security parameters, but with HTTP/1.X.

Of course, hard failure always poses a risk for interop / web compat
issues. But it prevents this sort of downgrade attack. I think the
risk is low for new ALPN tokens. So, I think client implementations
probably should start hard failing. I haven't thought through the
non-browser scenarios, so maybe there's a reason not to hard fail for
other clients.

Anyway, food for thought. I'm curious what others think.

Received on Thursday, 30 January 2014 01:04:51 UTC