Re: [TLS] SCSV versioning

Bodo Moeller <> Thu, 26 February 2015 21:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 938A41A8843 for <>; Thu, 26 Feb 2015 13:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.638
X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fEbQyaQwk42V for <>; Thu, 26 Feb 2015 13:06:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB21D1A87B0 for <>; Thu, 26 Feb 2015 13:06:32 -0800 (PST)
Received: from ([]) by (mreue003) with ESMTPSA (Nemesis) id 0MOELI-1YUPYI47L2-005Z7R for <>; Thu, 26 Feb 2015 22:06:31 +0100
Received: by with SMTP id wp4so14197101obc.10 for <>; Thu, 26 Feb 2015 13:06:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id 69mr7082702oim.50.1424984789778; Thu, 26 Feb 2015 13:06:29 -0800 (PST)
Received: by with HTTP; Thu, 26 Feb 2015 13:06:29 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Thu, 26 Feb 2015 16:06:29 -0500
Message-ID: <>
From: Bodo Moeller <>
To: 🔓Dan Wing <>
Content-Type: multipart/alternative; boundary="001a113d0d16348af50510042060"
X-Provags-ID: V03:K0:jTnvgMXNpqLY+/qsCjMmWCLooW2OblNPKBiCF6TflHt20isgOfM t0Z9mWtHx6hle5ha0iwdJPd3DVHHxuXcWTdaUnlksggtz8O077ogHfZITdUszL7GIJUfGJ8 kNnX6rijquVJiZ0L83s+g3xZB8eCAYV+KwJyOCtPcyjFJoUN8cb+GBPfsOtxwmmw/sgZcq9 2+frYb0d8p9YDxZjAKCdw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] SCSV versioning
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: Thu, 26 Feb 2015 21:07:09 -0000

Dan Wing <>:

I recently became aware that Microsoft IE won't implement SCSV.  Near as I
> can tell, this is the main concern [...]:

> One of the developers pointed out that the TLS_FALLBACK_SCSV feature has
> a significant downside-- because it doesn't convey any specific version
> information, it becomes a general "never fall back" signal. The problem is
> that such signals are too broad; fallbacks were only ever introduced
> because servers often use TLS stacks with implementation bugs. Any "don't
> fallback" signal sent by such a server will be very bad for compat.

I haven't seen this particular complaint before, and also can't quite make
sense of it. TLS_FALLBACK_SCSV is a signal sent by the client, not by the
server as that statement implies (and of course, IE acts as a client). The
specification (draft-ietf-tls-downgrade-scsv-05) says that clients SHOULD
send TLS_FALLBACK_SCSV in fallback handshakes, and that servers MUST react
to it in a specific way. This expressly gives clients some latitude,
allowing trade-offs that may be needed for the sake of compatibility.
(Also, if a client never does a fallback handshake, there's no reason to
send TLS_FALLBACK_SCSV in the first place.)

A related (in a Chinese-whispers way, anyway) complaint that I *have* seen
is the one I've addressed in  (See also