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

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 29 Jan 2014 17:04:24 -0800

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.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 30 Jan 2014 11:40:10 -0500

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.

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 30 Jan 2014 09:41:25 -0800

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" <[email-masked]> wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Jan 2014 10:03:58 -0800

It feels like you are instantiating specific crypto algorithms that might
change in the near future (see the active discussions in the CFRG and TLS
WG) and thus making establishing HTTP/2 brittle. Instead, why don't you
just say that either party MAY remove HTTP/2 from the negotiation of the
other party's crypto does not meet its requirements? You can suggest
requirements (128 bits of strength seems good), but if *both* parties want
lower TLS crypto requirements (such as in constrained devices that are not
using EC), it seems odd that the base spec says "you can't do HTTP/2". That
is, TLS with encryption is still a MUST, but how good the encryption or key
exchange is seems like the opening of security theater.

On Thu, Jan 30, 2014 at 9:41 AM, William Chan (陈智昌)
<[email-masked]>wrote:

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

---

From: Michael Sweet <[email-masked]>
Date: Thu, 30 Jan 2014 13:19:08 -0500

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 (陈智昌) <[email-masked]> 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.
>

---

From: Brian Smith <[email-masked]>
Date: Thu, 30 Jan 2014 11:31:09 -0800

On Thu, Jan 30, 2014 at 9:41 AM, William Chan (陈智昌)
<[email-masked]> wrote:
> 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

I agree with you. I think it would be good if we implemented this
hard-fail behavior before the next interop meeting. Then we will
really find out if/how the TLS requirements are problematic.

FWIW, this is now Mozilla bug 965922:
https://bugzilla.mozilla.org/show_bug.cgi?id=965922.

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jan 2014 15:03:53 -0800

> introduce a potential downgrade attack.

I think that without an actual analysis, sharing "bad feelings" only
really amounts to scaremongering.

True, we want to use HTTP/2 as an inducement for upgrading your TLS
stack.  But so far, I've seen no evidence that HTTP/2 is intrinsically
"more secure" than HTTP/1.1.

If anything, with header compression and coalescing, it's possible
that it could be worse in HTTP/2.  I consider the fact that it is
easier to correctly implement HTTP/2 over HTTP/1.1 as something of a
non-difference, though I will concede that in some cases this has been
an issue.

> really find out if/how the TLS requirements are problematic.

That's why it's in there.