Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate

Hanno Böck <> Tue, 10 November 2020 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD75F3A0E7C for <>; Tue, 10 Nov 2020 11:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HoGuxkN2yxcM for <>; Tue, 10 Nov 2020 11:15:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 088F43A0E74 for <>; Tue, 10 Nov 2020 11:15:48 -0800 (PST)
Received: from computer ([2a02:8109:83c0:5eee:d603:5dcc:f25d:e5e0]) (AUTH: PLAIN, SSL: TLSv1.3, 256bits, TLS_AES_256_GCM_SHA384) by with ESMTPSA id 00000000000000DD.000000005FAAE6E1.00002CE2; Tue, 10 Nov 2020 20:15:45 +0100
Date: Tue, 10 Nov 2020 20:15:44 +0100
From: Hanno =?iso-8859-1?q?B=F6ck?= <>
Message-ID: <20201110201544.0d56a125@computer>
In-Reply-To: <>
References: <>
X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate
X-Mailman-Version: 2.1.29
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: Tue, 10 Nov 2020 19:15:51 -0000

On Tue, 10 Nov 2020 20:40:57 +0200
Yaron Sheffer <> wrote:

> I think marking the “oldversions” draft as “obsoletes RFC 7507
> (SCSV)” is not great from an ecosystem point of view. People will
> interpret it as “no need to implement SCSV in new code, no need to
> expose it as a configuration option in existing code”. And we know
> that some admins will continue to allow downgrade to TLS 1.0/1.1 no
> matter what we tell them.

Is this true?

To clarify: We're not talking about people supporting TLS 1.0/1.1 (of
which there are obviously still many), we're talking about clients
doing out-of-protocol downgrade dances where they will attempt to
connect via TLS 1.0/1.1 if TLS 1.2 connections fail. That's the only
scenario where SCSV is needed.
AFAIK the only clients that ever did these out of protocol downgrades
were browsers and they all disabled this behavior in the meantime.

I would assume it's very likely that SCSV serves no useful purpose today
and hasn't done so for years.

Hanno Böck