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

On Thu, Jan 30, 2014 at 3:03 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On Thu, Jan 30, 2014 at 9:41 AM, William Chan (陈智昌)
> <willchan@chromium.org> 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 <brian@briansmith.org> 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?

Received on Saturday, 1 February 2014 17:20:32 UTC