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

William,

Still, it seems like if both sides want to use ALPN but one side doesn't like the cypher suites (or TLS version) the other is offering, then the normal fall back logic should apply, including aborting on either end if compatible settings cannot be negotiated - there is nothing inherently special about HTTP/2.0 in this.


On Jan 30, 2014, at 12:41 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> I guess I'm advocating that a server must not select http/2 in alpn until it's sure it supports the base TLS profile. And if the server fails to do so correctly, the client hard fails. I do not believe we have backwards compatibility issues since the h2 token is new. Clients only have an opportunity to tighten requirements when introducing new alpn tokens. Any attempt to do so with existing tokens will probably require fallback and introduce a potential downgrade attack.
> 
> On Jan 30, 2014 8:40 AM, "Michael Sweet" <msweet@apple.com> wrote:
> 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
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair