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 (Martin Rex) Fri, 16 January 2015 23:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 70E6B1A8987; Fri, 16 Jan 2015 15:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T2i27-zVEPb8; Fri, 16 Jan 2015 15:08:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CB631A897C; Fri, 16 Jan 2015 15:08:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E604C3A564; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id D4A7442219; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
Received: by (Postfix, from userid 10159) id CA2D91B0FA; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
In-Reply-To: <>
To: Brian Smith <>
Date: Sat, 17 Jan 2015 00:08:10 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <>
Archived-At: <>
Cc: "" <>,
Subject: 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
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Jan 2015 23:08:16 -0000

Brian Smith wrote:
> Adam Langley <> wrote:
>> On Fri, Jan 16, 2015 at 12:03 PM, Hanno Böck <> 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.