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

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 <paul.hoffman@gmail.com> 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 (陈智昌) <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
>>>
>

Received on Saturday, 1 February 2014 17:53:00 UTC