Re: [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Keith Moore <moore@network-heretics.com> Tue, 01 December 2020 00:40 UTC

Return-Path: <moore@network-heretics.com>
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 A821B3A12E2; Mon, 30 Nov 2020 16:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 JdOUtgpOZKXb; Mon, 30 Nov 2020 16:40:39 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007933A12F2; Mon, 30 Nov 2020 16:40:38 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5FADC5C0182; Mon, 30 Nov 2020 19:40:38 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 30 Nov 2020 19:40:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=N1JFFHmXyYEg/NhJVASS/nJDBzYcQxJEzI5z0BxHI I4=; b=LaPxeY2kQCNxzka27GF5HmhxDDy+XuzXkSIqr8y+fe4UNDr/AszgR4vzt NNgUW5uOAPn25OZ8Bfv9UAgr4sP73NoDBcDkCIgUwjRD5aJtZkJqF8YPnJ2nRf/j RSFjDWwmPZkMwy9M90ejvwlRcwfR2OMdFLM8ZmROAWOxMUt3+BLHP2jvoFRH0e6c DdsDhVOpQf2UqNbXpY0oDKjTrguwoe3F+7v7dEN9pUqs4LlhU7Lq6UO/vgFM6yl+ bFpO57G0oBvTlYnMYZeocuImm7jV5L83gaxbNpXS7cwK8rHIyttfwjEbCWElV9dd mtNyCtPixqTID8rUtbeP9tPiAAEUw==
X-ME-Sender: <xms:BZHFX10cGsN7v3xJ-E1IGGYjgNv0VzheKkdSoPXE-_rXRjEecIcoXg> <xme:BZHFX8G9S5tO57CvN73zymR5SokwZS4cUauN9dCLnCHEGQ76daYFD_KK_5nIUmGI_ fSdBUCKrT7DNA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeiuddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefheenucfhrhhomhepmfgvihht hhcuofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh eqnecuggftrfgrthhtvghrnhepheduhfeludegueetveevhfeujeejfefffeettedtvdel fefgkeeikeehjeffvdffnecukfhppedutdekrddvvddurddukedtrdduheenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:BZHFX16JB2_aMu2k2yIX86s48fIn0mmyFhlqzM-KbY28r5sgtaDcAg> <xmx:BZHFXy1dK3delqaMI9c5aseElKMqOpZC_wmr_6iDoQgMD_zG-8h4vw> <xmx:BZHFX4He7NpXWJ-Fm-fIL546WErRTE8NOH3DNbog33UHCOa613J1eA> <xmx:BpHFX9TaKlvKV97E8o_g53fSzIU_MWvRA8a5vjLkGUHt_r5-0CSfyA>
Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 44A7F3280060; Mon, 30 Nov 2020 19:40:37 -0500 (EST)
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "last-call@ietf.org" <last-call@ietf.org>
Cc: "draft-ietf-tls-oldversions-deprecate@ietf.org" <draft-ietf-tls-oldversions-deprecate@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <49d045a3-db46-3250-9587-c4680ba386ed@network-heretics.com> <b5314e17-645a-22ea-3ce9-78f208630ae1@cs.tcd.ie> <1606782600388.62069@cs.auckland.ac.nz>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <d37933bf-1272-9118-9d91-d3e90d517b32@network-heretics.com>
Date: Mon, 30 Nov 2020 19:40:34 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <1606782600388.62069@cs.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BHLQ_tJ2xscwF2Tb6V47vwTr44E>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
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, 01 Dec 2020 00:40:47 -0000

On 11/30/20 7:29 PM, Peter Gutmann wrote:

> So I think the text should include wording to the effect that it applies to
> public Internet use but not to embedded/SCADA/etc for which very different
> considerations apply.

I've been thinking something like this also.  But IMO there are still 
valid cases for negotiating older versions of TLS on the public 
Internet, such as the mail relaying case mentioned earlier.    So far I 
haven't thought of a reason where either (a) bouncing an email message; 
(b) resending it in cleartext; or (c) discarding it, is better than 
relaying with TLS 1.0 or 1.1. (Though maybe there aren't enough MTAs 
that do opportunistic TLS using version <= 1.1 to matter.)

More generally, the right remedial behavior for an application with e2e 
connectivity and an interactive UI that can't do better than TLS 1.1, 
isn't necessarily the right behavior for all applications.

So maybe two restrictions on scope?  (1) public Internet; (2) e2e and 
interactive application?

But it's important to understand that protocols and protocol 
implementations that are used on the public Internet are also used on 
isolated and mostly-isolated networks.

Given that this is BCP and not standards-track, maybe it should just be 
made clear that an implementation that does support 1.0 or 1.1 isn't 
necessarily violating the standard, it's just discouraged as a practice.

Keith