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

[Bodo Moeller <[e-mail]>]

Martin Rex <[e-mail]>:


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

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

To be entirely clear, there's obviously no security improvement from
TLS_FALLBACK_SCSV for clients that never use fallback connections, and for
servers that only have clients without such fallback strategies.

The older protocol versions have some very real security problems.  I don't
think it's relevant that, as far as we know, these security problems are
not currently routinely exploited by attackers.



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


Deploying TLS_FALLBACK_SCSV on even just a single server is sufficient to
protect connections to that server.  Clients can use it without having to
wait for all servers to be updated.

If we can also get all servers fixed so that there's no longer a need for
potentially insecure fallback connections, all the better, but it's
certainly going to take longer before clients can be updated to benefit
from that kind of change.  The TLS_FALLBACK_SCSV specification does not
prevent any such effort -- we don't have to choose between *either*
deploying TLS_FALLBACK_SCSV *or* fixing the protocol properly.  (The
TLS_FALLBACK_SCSV Internet-Draft is intentionally agnostic about what a
proper fix would look like.  Once we manage to fix the protocol, clients
would simply stop to send TLS_FALLBACK_SCSV, while servers would continue
to watch for it.)

So I don't agree with the word "preferable": it suggests that the options
are mutually exclusive, when in fact they are not.

Bodo