IETF Logo Mail Archive

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

Benjamin Kaduk <kaduk@mit.edu> Tue, 13 October 2020 19:15 UTC

Return-Path: <kaduk@mit.edu>
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 7ECBF3A10BD; Tue, 13 Oct 2020 12:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 QI--FtwoLGKm; Tue, 13 Oct 2020 12:15:20 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08163A1045; Tue, 13 Oct 2020 12:15:18 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09DJFCvd007348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Oct 2020 15:15:16 -0400
Date: Tue, 13 Oct 2020 12:15:12 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael D'Errico <mike-list@pobox.com>
Cc: TLS List <tls@ietf.org>, draft-ietf-tls-oldversions-deprecate.all@ietf.org
Message-ID: <20201013191512.GD83367@kduck.mit.edu>
References: <20200726212223.GY41010@kduck.mit.edu> <CAHbuEH6YV5HyqEV7DbO=_-9yFEHTS3Q7nH_t=ap_xwzGK=vMWw@mail.gmail.com> <20200813175413.GY92412@kduck.mit.edu> <B1F480D7-437B-48E1-969A-D30D3598CF9D@sn3rd.com> <20201013183420.GB83367@kduck.mit.edu> <263ebc32-e908-4e41-a8d8-37e88da970ee@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <263ebc32-e908-4e41-a8d8-37e88da970ee@www.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GXtbbbmAgRbeTWesx16D3K6wNnc>
Subject: Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06
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, 13 Oct 2020 19:15:22 -0000

Hi Mike,

On Tue, Oct 13, 2020 at 03:09:15PM -0400, Michael D'Errico wrote:
> I know that saying this will have no effect, but I'd
> rather see deprecation of just TLS 1.0 and retain
> version 1.1 as not recommended.

Saying that it's your preference without saying why is likely to have
little effect, yes.  (We endeavor to make decisions based on technical
merit, not voting, after all.)  Why do you want this?  TLS 1.1 seems to
have minimal usage (less even than 1.0) and is much closer to 1.0 than 1.2
(let alone 1.3) in terms of design and safety.

> Also, we should not abandon RFC 7507 (downgrade
> protection SCSV).  What harm is there in keeping it
> around?  None.

I don't expect implementations to abandon SCSV any faster than they abandon
TLS 1.0 or 1.1.  But if the official advice is that 1.0 and 1.1 are
obsolete, then the official advice should also be that SCSV is obsolete --
its function is performed in a different way by the newer versions of TLS.

-Ben

v2.23.0 | Report a Bug | By Email