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)]

Brian Smith wrote:
> Adam Langley <[e-mail]> wrote:
>> On Fri, Jan 16, 2015 at 12:03 PM, Hanno Böck <[e-mail]> wrote:
>>> Recently Mozilla has disabled the now so-called protocol dance, which
>>> makes adding another workaround (SCSV) pretty much obsolete:
>>
>> Until they add TLS 1.3 support, when they'll need it again.
> 
> I don't think so, because we can change the way versions are
> negotiated for TLS 1.3, so that the issue doesn't arise. In
> particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2)
> and negotiate TLS 1.3 with an extension.
> 
> Also, the rate of TLS 1.3 intolerance might be significantly lower
> than projected. Ivan's numbers are based on a ClientHello with 0x0304
> (TLS 1.3) as the record-layer version number. We know from past
> experience working on NSS that 0x0301 (TLS 1.0) is a more compatible
> record-layer version number. I think it was established that many
> servers work fine when ClientHello.client_version = 0x0304 (TLS 1.3)
> as long as the record-layer version number is 0x0301 (TLS 1.0) but
> break when then record-layer vsion is 0x0304 (TLS 1.3).


Sending { 0x03, 0x04 } at the record layer for the ClientHello at the
beginning of a new connection MUST be expected to get unconditionally
rejected by pre-TLSv1.2 servers.  It puzzles me to why so many implementers
get this wrong.

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

But what was a really bad idea was neither offering a user an opt-in
for individual downgrades, nor allowing the user to disable the downgrade
dance.  Also not attempt was made to count how often downgrades happened,
nor to limit how often browsers would perform automatic silen downgrades.
This gross negligence was one of the reasons why the brittle connection
management in Firefox, that regularly caused downgrades all by itself,
was (a) unnoticed by the responsible developers and (b) was ignored
for almost 6 years after reported as an easily reproducible FF bug...


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.


-Martin