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: Paul Hoffman <paul.hoffman@gmail.com>
Date: Sat, 1 Feb 2014 20:18:28 -0800
Message-ID: <CAPik8ybYXHVyttOJ7Y5tndkCmMRRGYg5Jf_DamUnv4wmg7KriQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Michael Sweet <msweet@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Feb 1, 2014 at 9:52 AM, William Chan (陈智昌) <willchan@chromium.org>wrote:

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

Both: your question (assertion, really) about handling negotiation failure
is predicated on particular types of failures, and the question of what to
do with an extension failure is quite different than the question of what
to do when two parties can agree to strong crypto that happens not to meet
the requirement in the spec.

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

So, you are discussing the requirement. If that requirement didn't exist,
you would still (quite properly) be discussing what to do when there are
extension failures.

> If you disagree with mandating negotiation failure based on
> certain TLS properties, maybe fork this thread so others don't get
> confused?

 This feels a bit disingenuous. Your question was how to downgrade under
cases A, B, and C, with the strong implication that it would be the same
for all three cases. I pointed out that one case should be treated
differently because it makes HTTP/2 establishment unnecessarily brittle
even when both parties agree to secure ciphersuites.
Received on Sunday, 2 February 2014 04:18:56 UTC

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