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

[Bodo Moeller <[e-mail]>]

Michael D'Errico <[e-mail]>:


> We should consider whether we can define a single SCSV that a
> client issues when it thinks a server is extension intolerant.
>
> Such an SCSV could be used in conjunction with a normal extension
> used for downgrade protection, if the client gets pushed all the
> way back to TLSv1.0 without extensions, or to SSLv3.
>
> This approach could solve the problem of desiring more SCSVs in
> the future.


Hm, that would mean having the SCSV for special-case downgrade protection
(extension intolerance) and an extension for general-case downgrade
protection (when extension intolerance is not an issue).  That means
requiring more code to be added to servers (to *all* servers, since these
mechanisms only work as intended if all servers support them).  In
practice, what would be gained from that over just having the SCSV and
using it for both?

(If someone really wanted to add a new negotiation mechanism for anything
and allow it to be backported to SSL 3.0 implementations with no extension
support, they'd *still* want a new SCSV for that ...  however, I hope that
with the protocol downgrade issue getting addressed, the need to support
any other new protocol tweak to these obsolete protocol versions will go
away.  For example, draft-gutmann-tls-encrypt-then-mac-05 doesn't need an
SCSV when you can use TLS_FALLBACK_SCSV to avoid falling back to old
protocol versions.)

Bodo