- From: Jason Greene <jason.greene@redhat.com>
- Date: Tue, 30 Sep 2014 23:38:09 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Greg Wilkins <gregw@intalio.com>, "FOSSATI, Thomas (Thomas)" <thomas.fossati@alcatel-lucent.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sep 30, 2014, at 10:27 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 30 September 2014 20:15, Jason Greene <jason.greene@redhat.com> wrote: >> A TLS 1.3 stack will accept a TLS 1.2 client using a cipher which a compliant HTTP/2 stack will then reject. > > How is that possible? I'm not saying that my understanding is > perfect, but I believe that's impossible. So the current TLS 1.3 draft allows a TLS 1.3 server to accept connections for anything from SSL 3 to 1.3. A TLS 1.2 client can specify a block cipher like AES256-CBC, and that will be accepted by the TLS stack (unless of course the TLS implementation has been operationally configured not to allow it). Such ciphers aren’t bad, they just aren’t state of the art, and are accepted by major websites/servers right now. They will likely continue to be supported as well since sites wish to remain compatible with legacy devices and software. If the client uses HTTP/1.1 and TLS 1.2 talking to a TLS 1.3 server, using CBC it will all work fine. However, if the client uses HTTP/2, and CBC ends up getting negotiated, then the server needs to reject with INADEQUATE_SECURITY. So HTTP/2 is asserting additional restrictions beyond what a TLS 1.3 stack would natively do. Since both HTTP/1.1 and HTTP/2 share the same port, a dual h1/h2 stack will be forced to do fiddly things to allow ciphers from H1 that it will disallow on H2. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Wednesday, 1 October 2014 04:38:46 UTC