- From: Jason Greene <jason.greene@redhat.com>
- Date: Mon, 3 Nov 2014 09:21:20 -0600
- To: Brian Smith <brian@briansmith.org>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> > On Oct 31, 2014, at 10:49 PM, Jason Greene <jason.greene@redhat.com> wrote: > >> No, it doesn't have to reject XYZ. It can carry on based on the assumption that XYZ is OK. If it is, then the client will accept it. If it isn't, the client will return INSUFFICIENT_SECURITY to the server. (Keep in mind that this is only in the worse case where the server's HTTP/2 implementation is based on a TLS stack that is too inflexible to do better things.) > > But that would violate 9.2.2 which clearly refers to both parties. I agree that it would be better if the language where changed to say that the client MUST and the server SHOULD, and would be in favor of that change. That would certainly address the interop issue, but it would still leave the possibility that an h2 client would exclude stronger ciphers than the TLS implementation supports, since the h2 stack may not yet be aware of them. I have some proposed text for this option here: https://github.com/http2/http2-spec/pull/639/files -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Monday, 3 November 2014 15:21:54 UTC