Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate
Hanno Böck <hanno@hboeck.de> Tue, 10 November 2020 19:15 UTC
Return-Path: <hanno@hboeck.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD75F3A0E7C for <tls@ietfa.amsl.com>; Tue, 10 Nov 2020 11:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoGuxkN2yxcM for <tls@ietfa.amsl.com>; Tue, 10 Nov 2020 11:15:49 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088F43A0E74 for <tls@ietf.org>; Tue, 10 Nov 2020 11:15:48 -0800 (PST)
Received: from computer ([2a02:8109:83c0:5eee:d603:5dcc:f25d:e5e0]) (AUTH: PLAIN hanno-default@schokokeks.org, SSL: TLSv1.3, 256bits, TLS_AES_256_GCM_SHA384) by zucker.schokokeks.org 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 Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20201110201544.0d56a125@computer>
In-Reply-To: <912FCE0F-65C4-487B-8121-748466BB2FB9@gmail.com>
References: <912FCE0F-65C4-487B-8121-748466BB2FB9@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/tls/yiJEcrOYD8A5dh00tS3VM7cCcfY>
Subject: Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2020 19:15:51 -0000
On Tue, 10 Nov 2020 20:40:57 +0200 Yaron Sheffer <yaronf.ietf@gmail.com> 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 https://hboeck.de/
- [TLS] Obsoleting SCSV in draft-ietf-tls-oldversio… Yaron Sheffer
- Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldve… Hanno Böck
- Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldve… Loganaden Velvindron