- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 10 Oct 2014 09:51:24 -0500
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Oct 10, 2014, at 6:09 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > > What about following case: > > 1) Client sets priority "NORMAL:-KX-ALL:+PFS:-MAC-ALL:+AEAD" (offer only > (most of) 9.2.2-compliant ciphers). > 2) Client sets mandatory ALPN to ["h2"] (HTTP/2 only). > 3) Client connects to server. > 4) Server TLS stack picks ALPN "h2" and ciphersuite XYZ (must be 9.2.2- > compliant because of 1). > 5) The HTTP/2 stack has no (or only partial[1]) idea what XYZ is. > > Does the server generate INADEQUATE_SECURITY? > > If yes, you get interop failure (with client that did nothing wrong). > > If no, one potentially lets some[2] non-9.2.2 ciphers through. This proposal is certainly a major improvement, but I think they only it can work if it exhaustively lists the allowed h2 ciphers, which effectively means new ciphers require either TLS 1.3, or an update to the RFC to list them. I’d be ok with something like this, and would look forward to TLS 1.3 coming out soon, and hope this ugly hack vanishes. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Friday, 10 October 2014 14:52:07 UTC