Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

[Daniel Kahn Gillmor <[e-mail]>]

On 01/24/2014 04:05 PM, Martin Rex wrote:
> The server is definitely the wrong peer to guess whether
> the client wants to continue or abort TLS handshake.

In the fallback scenario this SCSV is designed to address, the server
normally has no knowledge that the client's prior attempts to connect
with a reasonable protocol version had failed.

By transmitting this SCSV, the client is saying to the server "just so
you know, i tried a better protocol, but it didn't work -- if you meant
to accept better protocols, then someone is messing with us, please abort."

The server knows whether it believes it can accept better protocols, so
it is in the right position to make this call.   I support adoption of
this draft by the WG.

However, there is a risk that clients will offer the SCSV when other
non-version handshake parameters have changed (e.g. different
ciphersuites were offered, or extensions present in normal connections
that are removed in a fallback "compatibility" mode).  I'm assuming that
clients generally don't want to do multiple layers of fallback, each
time testing removing a particular extension or protocol or version or
ciphersuite; instead, i suspect clients will prefer a "normal mode" and
then a lowest-common-denominator "fallback mode".  In this scenario, it
does seem plausible that the SCSV could trigger a connection abort that
otherwise wouldn't happen.  Is there guidance we can give to server or
client implementors to mitigate this risk?

	--dkg