W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: 陈智昌 <willchan@chromium.org>
Date: Sat, 1 Feb 2014 10:13:00 -0800
Message-ID: <CAA4WUYjP_6+RpHTKU1ympX=3_MpOPftozNW4oL=g7MT=tWfjdA@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 <msweet@apple.com> 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 (陈智昌) <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
>
Received on Saturday, 1 February 2014 18:13:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC