Re: Concluding discussion on #612 (9.2.2)

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? That
is a pretty strange case, but then real world deployments do through up
strange things like this, so the handshake must handle.

But what I'm advocating is that if a client offers a protocol/cipher pair -
then either it will accept it's use or it MUST retry with protocol/cipher
pairs that it will accept.   So I will change my PR so that instead of
saying it must fallback to h1, to instead say that it must fallback to only
acceptable protocol/cipher pairs.

Offering unacceptable pairings and hoping the server will never see those
as acceptable is fragile.   If you don't like my proposals for a robust
handshake, then please make your own.   A fragile handshake is not an
option.

regards






-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.