Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Bodo Moeller <[e-mail]>]

Nikos Mavrogiannopoulos <[e-mail]>:

In any case,
> I don't believe how adding support for this extension on every
> implementation (in order for the protection to matter) is easier than
> fixing the few broken servers that don't properly do version
> negotiation.


Getting *every* implementation updated certainly is not easier. The
difference is that you don't have to -- the SCSV can be used (and indeed
*has* successfully been used) to protect against potential attacks when
connecting to servers that have been updated, while still allowing clients
to have kludgey interoperability with broken servers if they'd rather have
(potentially lower-security) connections to those than no interoperability
at all. As you know, browser implementors have widely seen a need for this.

At the same time, I completely agree that the broken servers must be shut
down too; but it's not either-or.


I believe there is little point for this protocol
> extension, given that the work arounds for the applications that use
> non-standard version negotiation are very straightforward (disable SSL
> 3.0).


Note that the SCSV is not tied to a particular protocol version. Also, we
see the step of disabling SSL 3.0 taken as a concrete *response* (while
still allowing downgrades to any TLS versions that clients may be willing
to fall back to). The SCSV can be used to protect against downgrade attacks
in general, *preventively*.

So unless you disables all protocol versions below TLS 1.2 now, supporting
the SCSV has demonstrable advantages in protecting against potential
attacks.

Bodo