Re: #612: 9.2.2 requirements

On 1 November 2014 05:35, Mark Nottingham <mnot@mnot.net> wrote:

> While some may consider the handshake “fragile”, they’ll need to explain
> how — given the above context — it affects interoperability in a way that’s
> significant. So far, I haven’t seen an explanation of how the handshake
> raises such an issue.


The problem with 9.2.2 is not that it tries to restrict TLS ciphers to
known good ciphers.   It is that is also tries to allow clients to continue
using known poor ciphers with http1 without any penalty.

If we all collectively just grew a pair and said that known bad ciphers are
not acceptable for HTTP (regardless of version) then the handshake would
not be fragile.

The interoperability problem comes because the handshake does not have the
expressive capability to clearly identify which ciphers are being offered
for h2 and which ciphers are being offered for h1 fallback to bad
ciphers.      This allows the handshake to fail when there is a mutually
acceptable  pairing of protocol and cipher.

I believe the best fix is to only allow h2 acceptable ciphers in the
initial handshake.      If the server fails to accept that connection
attempt, then IF WE REALLY HAVE TO, we can allow clients to retry a h1
connection with old weak ciphers.

The argument against this is that suffering an extra round trip is
unacceptable for the clients that wish to talk to these old weak
servers.     I believe that continuing to talk to such servers is
unacceptable, but if you really have to do it, then adding the round trip
is a good incentive to update ciphers/protocols.

If you want to protect against downgrade attacks, then just don't support
old weak ciphers regardless of the protocol spoken.


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.