Re: [TLS] SCSV versioning

Bodo Moeller <> Fri, 27 February 2015 02:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CABF41A6FF6 for <>; Thu, 26 Feb 2015 18:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 Sa7u1sUa8zLe for <>; Thu, 26 Feb 2015 18:25:17 -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 750FE1A1B6D for <>; Thu, 26 Feb 2015 18:25:17 -0800 (PST)
Received: from ([]) by (mreue005) with ESMTPSA (Nemesis) id 0M5tNd-1Xc5AI1A77-00xvmZ for <>; Fri, 27 Feb 2015 03:25:15 +0100
Received: by with SMTP id u20so13270378oif.12 for <>; Thu, 26 Feb 2015 18:25:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id jn3mr8469334oeb.68.1425003904087; Thu, 26 Feb 2015 18:25:04 -0800 (PST)
Received: by with HTTP; Thu, 26 Feb 2015 18:25:04 -0800 (PST)
In-Reply-To: <m28ufk15pf.fsf@localhost.localdomain>
References: <> <> <m2d24w19pi.fsf@localhost.localdomain> <> <m28ufk15pf.fsf@localhost.localdomain>
Date: Thu, 26 Feb 2015 21:25:04 -0500
Message-ID: <>
From: Bodo Moeller <>
To: Geoffrey Keating <>
Content-Type: multipart/alternative; boundary="089e0116126e81be3f051008932c"
X-Provags-ID: V03:K0:RWx7vYoSbPawLm7FtIJ6AKU2KRWozoNUIvwUiE190PiPKa4LuEB RNdhejkUbGRYG1c6xYOnNChfukj5PBLR3D5rgBDfp6VHwdl6Xsp8SzRI3HlEpl4MbjZ0Tu9 c5KT6mMz3av4L50jvzQpoYG6vquxbH9yalaNPoMBhXXyM2y6e+N5hHNSNLc2iiLSTsXn+Bb 4QTm3sAYq7b8ZyC/7aiKA==
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: Fri, 27 Feb 2015 02:25:19 -0000

> It affects any client which is talking to a server which is buggy and
> where the bugs can be avoided by a fallback.  For example, a server
> with an issue in its TLS 1.2 implementation (perhaps in an extension),
> which could be solved by retry and fallback with TLS 1.1 or without
> the extension, would instead be prevented from working by the SCSV.

Certainly.  However, now that a fair number of clients do support
TLS_FALLBACK_SCSV and use it in fallback retries (or may not fall back at
all), you should generally notice this kind of problem early as you try to
deploy the new server: this server just would be obviously broken and so
most likely won't make it far in its deployement.  So I think this is
extremely unlikely to become a concern in practice.

If you really were to try and do everything to interoperate with any kind
of theoretical server brokenness in your client, though, you'd end up with
lots and lots of retries -- you couldn't even rely on cipher suite
negotiation because the server might be getting individual cipher suites
wrong, for example.

The current reality of downgraded retries obviously isn't quite as
complicated, but is more complicated than just protocol versions.
TLS_FALLBACK_SCSV can take care of just one dimension, the protocol
version, because it's meant to be very simple (yet meaningful for security)
and because it would not make sense to perpetuate a snapshot of current
implementation brokenness in a protocol change.