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: Michael Sweet <msweet@apple.com>
Date: Mon, 03 Feb 2014 10:19:12 -0500
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <2392C0AF-BD36-4AD5-843E-399E741DF172@apple.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>

On Feb 1, 2014, at 1:13 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:
> 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"?

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

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

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.

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

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.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Monday, 3 February 2014 15:19:46 UTC

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