Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

"Martin Thomson" <mt@lowentropy.net> Fri, 27 September 2019 00:03 UTC

Return-Path: <mt@lowentropy.net>
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 A21371200D6 for <tls@ietfa.amsl.com>; Thu, 26 Sep 2019 17:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=VwOR6Sk5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rgZbFNzq
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 s__mb2FNuzKD for <tls@ietfa.amsl.com>; Thu, 26 Sep 2019 17:03:15 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46971202DD for <tls@ietf.org>; Thu, 26 Sep 2019 17:03:14 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 09F4921FC3 for <tls@ietf.org>; Thu, 26 Sep 2019 20:03:14 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 26 Sep 2019 20:03:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=CLROAHUGQJWMpTYcWG6U8VYt6ws45sc q46YVf+41Qjc=; b=VwOR6Sk5xSBYOwTUoLPiwlMJlaoMMUwSDJAUY+ztduTqohi Z6JdAzwiRi0X1gOreBHJE8G/O9FTJ5yBAhNkKx6qCIKxEC5a7DWxLBF3sJV928Py ijimSOSbnr14wdLYiFbxI7uzA/9Itg21q1LbP/cRsaC3IMnCtekWwDTunWRl7s3g SVI6/4Lfvs/28JcW1HZCcaDhMBzkInWi+Fs7oGTxT59HdasprzwOI1VLux7SrAZk g1nGEMXBhvyHqsKaWBBQGY/Qe/t5Qc7kUrcwWsZbgExKmqsikifIdd4MgWBpPnD3 y6aJ2aWlvP7EQH/AXZ6A4YQNUTbhZn0xmqcrYWw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=CLROAH UGQJWMpTYcWG6U8VYt6ws45scq46YVf+41Qjc=; b=rgZbFNzq+BOcQPokBtQgSQ fIU/MB4oWZR4rtzucKQW277PWTrn4Gs4vXNmtj/wbS58q6DlWhma+SHHG/tIKiN3 BXtXzEgizpo+0818Ng7JNxWlMxFfOXlnYFWFVjD7AKWE8o3eU/QXP2dYeioQuFgh ixiQjgogsMVuZxiMOYy+cOXpGD4XtlZUQIeIo0Rohj6bomBMOxJG1ykcZ0I6oJIl xvIXFd3PMAsWNYT+WtIvDc/nuBdJcC/XduQzj23yFbZ6A6WI8m664ID03e2KcYdR O8W/QkancqAIS0jGVUbGzMZq7cpzqbcNN+lHeSKK6Fl4QlDLCsfIzhsotryoUitg ==
X-ME-Sender: <xms:wVGNXZ_dwb1BiuK8BxCknyIvLSF4Pu1iJPvZ-3PJRyA6Xfixwt99Ng>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfeehgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:wVGNXeTq7DtfOnSn2OwB9beVpP0IAp99P8xy08pz6spClTQMU0UwOQ> <xmx:wVGNXSbuKgxDgywUKV3yLsa0OXbScRgiisFCs80e6zikEmyO6QtowA> <xmx:wVGNXQGX33_usjQ1pr1_hBrY9zYcl-Lb1q6VRbUHLkTXO-dXdAlx3Q> <xmx:wlGNXfeJA_qr4erTumfr8HlidhpKiW1Ck5EcVDInA_qvCS5w0aqx7g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 96498E00A5; Thu, 26 Sep 2019 20:03:13 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-305-g4111847-fmstable-20190924v1
Mime-Version: 1.0
Message-Id: <d4b01c69-6047-467b-8538-9780f6872fe1@www.fastmail.com>
In-Reply-To: <CADZyTknH0ivQc-xW-di1XKC7w-9A5TCF8vhLLCrR9jQbcqY5dw@mail.gmail.com>
References: <BF5F63A6-105B-47C6-8B65-29A290A16E76@akamai.com> <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> <CADZyTknH0ivQc-xW-di1XKC7w-9A5TCF8vhLLCrR9jQbcqY5dw@mail.gmail.com>
Date: Fri, 27 Sep 2019 10:02:54 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B7M7iCc9GHHL9hn05Jk38YX752Q>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
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: Fri, 27 Sep 2019 00:03:17 -0000

So I agree with Kathleen's conclusion: not to change the goals of the current document.  But there are changes that I think are necessary (and thanks to Daniel and John for highlighting these).

BTW, I've moved this to the TLS working group, because this is an active topic there and I don't see anything in my email that SAAG needs to concern itself with.

On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote:
> My understanding of deprecating of TLS1.0 TLS 1.1 is that: 
> a) new software do not use these versions 
> b) existing software stop supporting these versions. 

That differs from my perspective.

When we release a new version of something, we are sending a message:

1. new implementations and deployments MUST include support for newer versions
2. existing implementations and deployments SHOULD be updated to support newer versions

When we deprecate an old version of something, we are sending a message:

3. only use this old version if you absolutely have to
4. you are encouraged to take active measures to remove the need to use the old version
5. you have our support if you decide not to support this old version

Now, "support" from the IETF is about as meaningful as you think it is.  And you can s/MUST/really ought to/ and s/SHOULD/may wish to/ [RFC6919].

In browser-land, we've decided to form a coalition when it comes to removing TLS 1.0/1.1.  3GPP have obviously got their own support group, which seems to be functioning effectively, which is great.

> """The expectation is that TLSv1.2 will continue to be used for many 
> years alongside TLSv1.3."""

Some people have that expectation, but I think that John is right to challenge it.  There remain reasons that people are sticking with 1.2 for now, but those reasons are mostly to do with allowing time to flush out the vestiges of a dependency on some of the TLS 1.2 idiosyncrasies.

I would advocate for removing this statement and any residue of that sentiment from the draft.  It's speculation and, even if it were true, it conveys the wrong message.  The only message I would include is that one that is further down the document: "Any newer version of TLS is more secure than TLSv1.1."