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

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 1 Feb 2014 09:20:05 -0800

On Thu, Jan 30, 2014 at 3:03 PM, Martin Thomson
<[email-masked]> wrote:
> On Thu, Jan 30, 2014 at 9:41 AM, William Chan (陈智昌)
> <[email-masked]> wrote:
>> introduce a potential downgrade attack.
>
> I think that without an actual analysis, sharing "bad feelings" only
> really amounts to scaremongering.

I'm rather surprised at this strong language. At the very beginning of
the thread, I explicitly said it was just a "random blatthering of
thoughts from discussions with other Chromium folk". Are you seriously
saying that if we have potential concerns without analysis we should
not voice them because it equates to scaremongering? I don't even know
what the goal of any such scaremongering would be.

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

That's a fair analysis, and I'm not asserting that HTTP/2 is
intrinstically more secure. I merely suggested that from some angles,
it could be viewed as having enhanced security properties. It's
definitely also true that it may have some worse ones. But it's not
about whether or not HTTP/2 is overall more secure than HTTP/1.X, but
rather whether or not specific properties are stronger in HTTP/2 and
weaker in HTTP/1.X, such that a way to trigger a fallback from HTTP/2
to HTTP/1.X would enable exploiting such weakness. At least, that's my
random thought on the matter. I honestly haven't completely analyzed
this and was, as I've stated earlier, merely presenting this to the
working group for consideration.

>
> On 30 January 2014 11:31, Brian Smith <[email-masked]> wrote:
>> 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.
>
> That's why it's in there.

What's "it's" in this case? I see lots of normative language around
what must constitute a negotiation failure, but no language around how
to handle a negotiation failure...fallback or hard-fail?

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 1 Feb 2014 09:52:33 -0800

Sorry for the delayed response, was on a Chrome ski trip.

Paul, I'm not sure if I grok your response. Are you replying to my
question of how to handle negotiation failure, or to the base spec
mandating negotiation failure based on certain TLS properties
(extensions, ciphersuites, etc)? Note that the base spec's requirement
is already in there:  https://github.com/http2/http2-spec/issues/318 &
http://http2.github.io/http2-spec/#TLSUsage. I was not discussing that
requirement, but rather discussing what to do when the negotiation
fails. If you disagree with mandating negotiation failure based on
certain TLS properties, maybe fork this thread so others don't get
confused?

And if I misunderstood you and you actually understood what's already
in the spec and were asking me why I thought hard fail on negotiation
failure was a good idea, I believe I have already covered that earlier
and have answered why I am hopeful that it does not make HTTP/2
establishment brittle.

Cheers.

On Thu, Jan 30, 2014 at 10:03 AM, Paul Hoffman <[email-masked]> wrote:
> 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:
>>
>> 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
>> On Jan 30, 2014 8:40 AM, "Michael Sweet" <[email-masked]> 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 (陈智昌) <[email-masked]>
>>> 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
>>>
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 1 Feb 2014 10:13:00 -0800

I don't fully understand your paragraph, since you primarily assert
points of your own, but did not seem to address mine, AFAICT. Can you
clarify some points?

* What's "the normal fallback logic"?
* I asserted that, in some ways, HTTP/2 may have some better security
properties than HTTP/1.X (e.g. padding mechanism). When you said
"there is nothing inherently special about HTTP/2.0 in this", does
that mean you disagree?
* Do you disagree with the reasoning that, *if* HTTP/2 has certain
better security properties over HTTP/1.X, and *if* HTTP/2 negotiation
failure leads to fallback to HTTP/1.X, then a triggering a negotiation
failure could lead to a downgrade attack?

Cheers.

On Thu, Jan 30, 2014 at 10:19 AM, Michael Sweet <[email-masked]> wrote:
> 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:
>
>> 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.
>>
>>
>> > Some random blatthering of thoughts from discussions with other Chromium
>> > folk..
>> >

---

From: Martin Thomson <[email-masked]>
Date: Sat, 1 Feb 2014 13:17:51 -0800

On 1 February 2014 09:20, William Chan (陈智昌) <[email-masked]> wrote:
> Are you seriously
> not voice them because it equates to scaremongering?

It was a poor choice of words, I'll concede.  But I don't think that
hand-waving is constructive when it comes to identifying issues.  It
didn't take me long to conclude that this wasn't an issue.  I don't
want to discourage you from sharing input (I hope that could encourage
your colleagues to share as well; nameless others are hard to conduct
conversations with), but it would be nice if some more time was spent
on identifying problems more concretely.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 1 Feb 2014 13:42:25 -0800

It's not clear to me what "this wasn't an issue" means. I'm guessing
that means that what we have in the spec is OK and it's not necessary
to discuss how to handle negotiation failure and just let
implementations figure it out. That's fine by me.

I observe that as per
http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/Http2Session.cpp,
Firefox appears to hard fail. And my inclination is to enforce the
same policy in Chromium. This will affect other implementations that
wish to interoperate with these browsers.

As for the meta-procedural commentary, I disagree that all thoughts
must be fully baked before discussing in the open. But I've no
interest in debating that decision, so if the working group does not
want me/Chromium to share half-baked thoughts on stuff, that's fine
and I will stop sharing them. Sorry for the noise.

Cheers.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 1 Feb 2014 20:18:28 -0800

On Sat, Feb 1, 2014 at 9:52 AM, William Chan (陈智昌) <[email-masked]>wrote:

> (extensions, ciphersuites, etc)?

Both: your question (assertion, really) about handling negotiation failure
is predicated on particular types of failures, and the question of what to
do with an extension failure is quite different than the question of what
to do when two parties can agree to strong crypto that happens not to meet
the requirement in the spec.

> Note that the base spec's requirement
> fails.

So, you are discussing the requirement. If that requirement didn't exist,
you would still (quite properly) be discussing what to do when there are
extension failures.

> If you disagree with mandating negotiation failure based on

 This feels a bit disingenuous. Your question was how to downgrade under
cases A, B, and C, with the strong implication that it would be the same
for all three cases. I pointed out that one case should be treated
differently because it makes HTTP/2 establishment unnecessarily brittle
even when both parties agree to secure ciphersuites.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 03 Feb 2014 10:19:12 -0500

William,

> * What's "the normal fallback logic"?

Typically: TLS/1.2 -> TLS/1.1 -> TLS/1.0 -> SSL/3.0 -> fail

And for HTTP/2 via ALPN, seems like this would simply become: TLS/1.2+HTTP/2.0 -> TLS/1.2+HTTP/1.1 ...

> "there is nothing inherently special about HTTP/2.0 in this", does

If I am understanding the current work of the TLS WG, all of the TLS padding enhancements apply to all uses of TLS, not just HTTP/2.0.  Requiring them for HTTP/2.0 conformance may be useful for security, but that doesn't mean that those same requirements cannot be used for HTTP/1.1, i.e., "downgrading" to HTTP/1.1 does not mean that you can't still use the TLS extensions - that is a TLS negotiation thing, not something unique to HTTP/2.0.

> failure could lead to a downgrade attack?

That's a big IF, but sure if you can't negotiate "more secure" TLS then you'll end up with "less secure" TLS/SSL.  But again, that isn't a HTTP/2.0 thing (aside from whatever minimum TLS requirements we might add) but a TLS thing.  And nothing says that a browser can't differentiate between "good" and "not-so-good" TLS, offer local policies to prevent the use of vulnerable ciphers, etc.  Let's just not start calling HTTP/2.0 more secure than HTTP/1.1 on the basis of TLS, since HTTP/2.0 does not require TLS and security is more than just good encryption.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 3 Feb 2014 10:43:11 -0500

> wish to interoperate with these browsers.
This seems like a no brainer to me.

HTTP/2 is negotiated via ALPN. If the server selects HTTP/2 and also does
something that is non-compliant with HTTP/2 that's a protocol error, not a
negotiation error.

afaict, failing to use TLS 1.2 is an example that isn't really any
different than sending a data frame > 14bits long. HTTP/2 has rules - if
you can't follow them then run a different protocol, right?

> and I will stop sharing them. Sorry for the noise.
phhhbt.

---

From: Rob Trace <[email-masked]>
Date: Wed, 5 Feb 2014 01:34:03 +0000

I am not sure this is such a no brainer.  We should not mandate implementation fallback behavior.  If an implementer would successfully negotiate HTTP 1.1 if HTTP/2 is failing, the implementer should decide how or when to fallback.  For example an implementer could decide that falling back to HTTP 1.1 and a different TLS profile is better than forcing a user to disable HTTP/2 to get to a given site.

-Rob

From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrick McManus
Sent: Monday, February 3, 2014 7:43 AM
To: William Chan (陈智昌)
Cc: Martin Thomson; Brian Smith; Michael Sweet; HTTP Working Group
Subject: Re: How to handle HTTP/2 negotiation failure WRT TLS

On Sat, Feb 1, 2014 at 4:42 PM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:

I observe that as per

This seems like a no brainer to me.
HTTP/2 is negotiated via ALPN. If the server selects HTTP/2 and also does something that is non-compliant with HTTP/2 that's a protocol error, not a negotiation error.

afaict, failing to use TLS 1.2 is an example that isn't really any different than sending a data frame > 14bits long. HTTP/2 has rules - if you can't follow them then run a different protocol, right?

phhhbt.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Feb 2014 13:31:00 +1100

What do people think about putting advisory text (not requirements) in Security Considerations?

On 5 Feb 2014, at 12:34 pm, Rob Trace <[email-masked]> wrote:

> On Sat, Feb 1, 2014 at 4:42 PM, William Chan (陈智昌) <[email-masked]> wrote:

--
Mark Nottingham   http://www.mnot.net/

---

From: Michael Sweet <[email-masked]>
Date: Wed, 05 Feb 2014 10:54:37 -0500

Mark,

I think that *if* a user agent includes the charset in the Authorization header, then that should indicate the user agent is providing RFC 5198 conforming UTF-8 (NFC, limits on control characters, etc.)  Existing clients that are already supplying UTF-8 would be unaffected, but if you tell the server you are using UTF-8, we need it to mean something specific or we still won't have interoperability.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 5 Feb 2014 15:51:45 -0800

Paul, just a few things here:
* I misunderstood you earlier. I thought you were talking about
negotiation failure in general, not just specifically the ciphersuite
requirement.
* I hope that explains why I think you should fork the discussion. I
hope you don't think I'm actually being disingenuous. I think we can
separately treat the discussion of what MUST cause negotiation
failure, and how to handle mandatory negotiation failure. IIUC, you
are advocating that the ciphersuite requirement not be mandatory
because two mutually consenting adults can agree to engage in sketchy
behavior together.

Cheers.

On Sat, Feb 1, 2014 at 8:18 PM, Paul Hoffman <[email-masked]> wrote:
> do with an extension failure is quite different than the question of what to
> do when two parties can agree to strong crypto that happens not to meet the
> requirement in the spec.
>
>>
> cases A, B, and C, with the strong implication that it would be the same for
> all three cases. I pointed out that one case should be treated differently
> because it makes HTTP/2 establishment unnecessarily brittle even when both
> parties agree to secure ciphersuites.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 5 Feb 2014 15:53:31 -0800

Is this a reply to the wrong thread? If not, I have to say I don't follow.

>> What do people think about putting advisory text (not requirements) in Security Considerations?

I suspect that we won't be able to come to consensus on mandatory
requirements for handling negotiation failure, so I think the
pragmatic approach is to add advisory text.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 07 Feb 2014 00:45:13 +1300

> What do people think about putting advisory text (not requirements) in Security Considerations?

I think prohibition of anything that makes it actually worse than
HTTP/1.1 over TLS is reasonable.

Otherwise just considerations sounds good. With a particular callout on
any possible security downgrades to HTTP/1.1 level of security.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 7 Feb 2014 13:08:29 +1100

OK. Let's try to get some text into SC of -10, at least -- Martin, do you want to take a stab at it?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Feb 2014 19:58:34 -0800

Yeah, I'll try to work something out. People already feel free to suggest
changes, so no big risk that I stuff things up.
On Feb 6, 2014 6:08 PM, "Mark Nottingham" <[email-masked]> wrote:

> >>> I am not sure this is such a no brainer.  We should not mandate
> implementation fallback behavior.  If an implementer would successfully
> negotiate HTTP 1.1 if HTTP/2 is failing, the implementer should decide how
> or when to fallback.  For example an implementer could decide that falling
> back to HTTP 1.1 and a different TLS profile is better than forcing a user
> to disable HTTP/2 to get to a given site.
> >>>
> >>> -Rob
> >>>
> >>> HTTP/2 is negotiated via ALPN. If the server selects HTTP/2 and also
> does something that is non-compliant with HTTP/2 that's a protocol error,
> not a negotiation error.
> >>>