Re: #612: 9.2.2 and ALPN

On 13 November 2014 13:20, Roy T. Fielding <fielding@gbiv.com> wrote:

> I don't think there is any scenario in which INADEQUATE_SECURITY
> needs to be sent.  A server that wanted to send it would have refused
> the TLS handshake (i.e., no good ciphers offered).  A server that doesn't
> want to send it isn't going to.  A client that does want to send it
> doesn't need to -- just drop the connection.  A client that doesn't want
> to send it is just going to make use of the completed connection, either
> to send an HTTP/1 request or to ignore 9.2.2 and send h2.
>


I think there are still a few scenarios that INADEQUATE_SECURITY can be
sent - but thankfully not many.

If the server offloads both TLS and ALPN, then both the cipher and protocol
choice may be made for it.   If the offloader selects a cipher in the BAD
set and h2, then the server can choose to fail the connection  or try it's
hand and see if the client will accept it or fail it.

In both cases, if the connection is failed, sure it can just be closed...
but I think it is more informative to send the INADEQUATE_SECURITY
code.       Hopefully this is now a very unlikely case, so when it does
happen having a sign post to say why will be very useful.

For me, the most important thing is that with the immutable black list of
BAD ciphers, a server now does not have to guess if the client was offering
a cipher for h1 only.   It has much better knowledge about the situation it
may find itself in.  It may still be constrained by limitations of TLS/ALPN
implementations, but that is still much better than not being constrained
and not knowing if a cipher will be accepted or not.

Note also, with a well defined h2 black list, then the scenario about can
be made even less likely by offloaders that implement ALPN having a special
case for the h2 black list.    I think it would have been unlikely that
offloaders would have implemented 9.2.2, but it is more likely that some
will provide a simple h2 black list, as it is far simpler to implement and
immutable.     It is still a hack, but at least now the hack is for the old
ciphers and old protocol and in 10 years time implementations will probably
be able to drop support for it and function perfectly ok.

cheers

-- 
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.