- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Sat, 11 Oct 2014 01:23:13 +0300
- To: Greg Wilkins <gregw@intalio.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Oct 11, 2014 at 08:38:23AM +1100, Greg Wilkins wrote: > On 10 October 2014 22:09, 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. > > > So the client send a handshake saying that it would only speak h2 and gave > a list of ciphers, some of which it is not prepared to speak h2 over? Nope, all ciphers it gave are both acceptable for it and 9.2.2-compliant. It is the server that doesn't know. It can't verify that XYZ is 9.2.2- compliant, nor can it know that XYZ is not 9.2.2-compliant. -Ilari
Received on Friday, 10 October 2014 22:23:38 UTC