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

William,

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