- From: ??? <willchan@chromium.org>
- Date: Tue, 7 Oct 2014 15:54:24 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Adam Langley <agl@google.com>
Explicitly +agl since he's not subscribed to the mailing list. And I'm deferring the Chromium/Google stance to him. On Tue, Oct 7, 2014 at 3:49 PM, Mark Nottingham <mnot@mnot.net> wrote: > > On 8 Oct 2014, at 9:10 am, Martin Thomson <martin.thomson@gmail.com> wrote: > >> On 7 October 2014 15:03, Greg Wilkins <gregw@intalio.com> wrote: >>> Clients MUST NOT advertise support of cipher suites that are prohibited by >>> the above restrictions if they advertise support for HTTP/2. If a >>> connection >>> is refused due to lack of a mutually acceptable cipher a client MAY retry >>> the >>> connection with weaker ciphers, but it MUST NOT offer support HTTP/2. >> >> I suspect that no browser can implement that requirement and remain competitive. > > I'm wondering if we should explore selectively relaxing the requirement to generate INADEQUATE_SECURITY, since that's where the pain seems to be coming from. > > E.g., if it were SHOULD/MAY, a party that wants to promote better security can do so by generating INADEQUATE_SECURITY, forcing fallback to HTTP/1 (and thereby losing the performance benefit of the protocol, giving an incentive to their peer to update). > > Those that don't wish to do so can simply not generate INADEQUATE_SECURITY. > > I think this should work as long as the fallback is interoperable (not necessarily performant). > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > >
Received on Tuesday, 7 October 2014 22:54:51 UTC