Re: How to handle HTTP/2 negotiation failure WRT TLS

William,

What about HTTP/1.1 servers that support https but not HTTP/2.0, ALPN, or the recommended cipher suites?

If I understand what you have written below, it sounds like you are advocating not supporting classic https using HTTP/1.1 with opportunistic HTTP/2.0 support?  Or am I missing something obvious here?

Seems like *if* a user agent isn't able to negotiate proper https+HTTP/2.0 support then it has to fall back on https+HTTP/1.1, otherwise every existing (https) web site will break.


On Jan 29, 2014, at 8:04 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair