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