- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 8 Oct 2014 09:49:03 +1100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
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:49:32 UTC