Re: [TLS] SCSV versioning

Geoffrey Keating <> Fri, 27 February 2015 01:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 20B4C1A0115 for <>; Thu, 26 Feb 2015 17:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZyAvxMtodq3t for <>; Thu, 26 Feb 2015 17:52:59 -0800 (PST)
Received: from (unknown []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81F011A00E5 for <>; Thu, 26 Feb 2015 17:52:59 -0800 (PST)
Received: by (Postfix, from userid 501) id F0AA533D050; Fri, 27 Feb 2015 01:52:28 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Bodo Moeller <>
References: <> <> <m2d24w19pi.fsf@localhost.localdomain> <>
From: Geoffrey Keating <>
Date: Thu, 26 Feb 2015 17:52:28 -0800
In-Reply-To: <>
Message-ID: <m28ufk15pf.fsf@localhost.localdomain>
Lines: 27
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 01:53:01 -0000

Bodo Moeller <> writes:

> > The implicit assumption made by the SCSV is that all new servers
> > (supporting the SCSV) will not have bugs requiring a fallback.  As
> > soon as that first server appears which supports SCSV but requires
> > fallback, this SCSV can't be used.
> This would affect fallback handshakes from *future* protocol versions to
> TLS 1.2, as we've seen that it's not a problem in practice when falling
> back from TLS 1.2 to earlier versions. So it could mean that clients that
> want to maintain interoperability with servers that can't handle their TLS
> 1.3 handshake attempts might not want to send TLS_FALLBACK_SCSV in fallback
> handshake Client Hello messages announcing TLS 1.2. (The document's
> Security Considerations cover this, by the way.) I don't see how it could
> be a reason to not use the SCSV when falling back to a version below TLS
> 1.2.

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.

As far as I know, there are no currently known examples of such
servers, but it doesn't seem unreasonable that such a thing might
appear in the future.