Re: [TLS] An SCSV to stop TLS fallback.

[[e-mail] (Martin Rex)]

Bodo Moeller wrote:
> 
> We can start to use TLS_FALLBACK_SCSV
> ASAP to improve security *ASAP* for connections to *those* servers that do
> get updated (80% or even just 10% is better than 0% -- if only the most
> important servers that users trust get updated, that's something).

Huh?  Your proposal is not going to improve the security one single bit.

Either the handshake goes through as initially proposed
(no TLS_FALLBACK_SCSV present in ClientHello), and therefore there can
not possibly be any improvement (or any effect).

Or the client's heuristics on network connectivity or handshake failure
from a connection attempt will result in an app-level reconnect fallback
to kick in and a new connection attempt with a more conservative ClientHello
with TLS_FALLBACK_SCSV asserted.  Either that handshake will succeed
as proposed (as if TLS_FALLBACK_SCSV wasn't present), or the handshake
will fail.

So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
of the TLS protocol not at all, or cause a fatal handshake failure.
And very few, if any at all, of the situations where the handshake fails,
will be instances of an active attack.  And it remains extremely
questionable, when the handshake would succeed, that the attacker
will gain anything at all.


I really do not see any benefit for servers to adopt support for this
interoperability problem.


For this feature to work at all, the prerequisite is that both communication
peers must be updated.  When looking at a protocol feature that requires
both communication peers to be updated as a prerequisite, wouldn't it be
preferable to fix those protocol features of SSL/TLS that we deem necessary
for reliable security to become negotiable even in the "most conservative"
ClientHello that clients are willing to fallback to?  This would make
the TLS handshake immune to "version downgrade" attacks  and allow
programmatic clients to offer TLS features (and cipher suites) that are
artificially and needlessly curtailed to the TLSv1.2 version number right
now to be negotiatiable in conservative ClientHellos.
This would completely obviate the fragile and complex app-level reconnect
fallback logic that is currently necessary to cope with failed TLS
handshakes caused by version-intolerant servers and dense middle boxes.


-Martin