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

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