Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[[e-mail] (Martin Rex)]

Martin Rex wrote:
> 
> Adding the aggressive automatic silent fallback reconnects
> (the "downgrade dance") to browser was not very smart.  The problems
> such fallbacks create was extensively discussed in the TLS WG in late 2009
> (renegotiation issue that resulted in rfc5746).
> 
> Making repetitive/frequent downgrades (e.g. more than 1 full handshake
> per host per hour) an interactive user opt-in, rather than the automatic
> silent can-not-be-disabled-by-user nuisance and security problem that it
> currently is, would immediately provide significant protection
> -- and entirely without server-side changes.  As a bonus, this would also
> help in identifying/reminding on server software/devices that should
> probably be updated.

For quite a while, Yngve Petterson has been proposing a scheme to
limit the downgrade dance problem (and willingness of clients/browsers
to perform the downgrade dance), that will work immediately, not require
and server-side changes, and without all of the massive serious operational
problems of the current fallback-scsv proposal:

  https://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-03


Rubber-Stamping the fallback-scsv hack onto the standards track is
IMHO a very bad idea.

I've once heard the saying "If you can't be good, at least be good at it."

If Browsers (and the few, if any) other TLS clients that are currently
doing the dangerous downgrade dances, can't be good and stop doing
such dangerous stuff, they should at least do this in a much less
risky fashion than what they're currently doing.

... such as adopting Yngve's approach above and do not perform downgrades
without interactive user confirmation where Yngve's proposal asks for a
handshake failure.


bottom line:  I am violently opposed to making the fallback-scsv
document a proposed standard.


-Martin