Re: #612: 9.2.2 requirements

On 5 November 2014 16:31, Yoav Nir <ynir.ietf@gmail.com> wrote:

> You are implying that TLS_RSA_WITH_AES_128_CBC_SHA is known insecure.
> This is not the case.


Not at all.

I'm saying that it allows a h2 handshake to include weak ciphers for the
purposes of h1 fall back:

   Clients MAY advertise support of cipher suites that are prohibited by
   the above restrictions in order to allow for connection to servers
   that do not support HTTP/2.  This enables a fallback to protocols
   without these constraints without the additional latency imposed by
   using a separate connection for fallback.

This is the clause that causes the handshake to be fragile, because the
ALPN protocol does not support differing cipher sets for each protocol.
So it is not possible for a server to distinguish between a unknown cipher
being offered as a h2 cipher or as a h1 fallback.

There are two linked conversations going on.  One about what ciphers we
should (or should not) restrict and one about the handshake. Some are
trying to argue that the definition of what ciphers to restrict is crystal
clear and future proof, so that the fragile handshake is not a
problem.         They may well be right, but they cannot prove that to be
the case.  Thus I am arguing that the handshake should be fixed - so that
if the future of ciphers does turn out to be less than crystal clear then
the result not a handshake failure.

If we have a robust handshake, then I am prepared to accept cipher
restrictions recommended by experts  even though I do not believe they
belong in an application protocol.

Without a robust handshake, I am not prepared to even attempt getting
involved in cipher negotiations. Jetty will just try to use whatever the
TLS layer negotiates regardless of protocol.

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.