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

Ted Lemon <mellon@fugue.com> Fri, 04 December 2020 17:20 UTC

Return-Path: <mellon@fugue.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 59FF63A0E3C for <tls@ietfa.amsl.com>; Fri, 4 Dec 2020 09:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 vyt2OZ7fYq9Q for <tls@ietfa.amsl.com>; Fri, 4 Dec 2020 09:20:39 -0800 (PST)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A3D3A0E3D for <tls@ietf.org>; Fri, 4 Dec 2020 09:20:39 -0800 (PST)
Received: by mail-qv1-xf30.google.com with SMTP id dm12so3124085qvb.3 for <tls@ietf.org>; Fri, 04 Dec 2020 09:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHBeYUr/LAPa3cRqWpozv31Trp+G3Dk8rqPuN6YE+lE=; b=O7PRMebJ2rAUjjOJ3pXx0uIUxAMXdivuZFcLmcd79ilb+ofOgH3KKMGHT91BfV6DdA GurFWDhO4a1nAHgG0WZ/arRms29+FZEOyNC0PlwnWhAuXPwt6xvVIkbhLAGukcXDXk6+ F+uyWKW+NxE2s/QbCcMsXW01UES60ObfV/nHteYbXsapMevRu1sMpD+mf2OM9clcFEJj vKSdlTNi9yvTlxoK++GyldLHh8P6pqZ1i4ksOT6VSk8ni0aIR58dqkoktvkdJpJRj24/ T86tsNt2Adm4HKWf6mB8AXEFwfS1Mo81/tRAkNgqj6a9ikP1vU0ip1hagDCgNQ59n0U7 SDig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHBeYUr/LAPa3cRqWpozv31Trp+G3Dk8rqPuN6YE+lE=; b=nZwmGdiWseqARKoqIWemui1tAcCuxpkMCrwyk8L2y4WtM5rHzf7rvng8CDRRQpWO/+ YhGMTKVrk89BdAhLQfn1LbaWqRp3lIHALCEm0TYO+Z+7cUprkXiggxT9FNd+l7ZbU8f7 nMEEsstl7/yKpc5oZGLl3S5gkJaumZlvgCZ+GFqcZ+YaYWL/CpJkfXOedqb04URSSIDP ptpYIQ6L2CdMDmDK7IpiVmxjfV7zbXgAzzjmfXAtb15T25OR0bQ9lqOZl6Fp/imhVki8 IAhDCXF2k12BHEeKK9OcZlUd2F+k0Ft8qhj32Cd6XOpCyiWiHC//a3rsCim2BL/6LgWv KSGQ==
X-Gm-Message-State: AOAM530utgPGz+b3nYKk7w2izgXb+tNM8jqwZQm3HHfbizWBozsnV4C3 8XcJINNS5W4/9IpCtnqsEEaFvw==
X-Google-Smtp-Source: ABdhPJzlJD43BW8ACZBv6s0EPUSe+szKgOGDjLm3ajH+ovlR72g+bMXFIbd+MsrCAlbWsgKkUNdcJA==
X-Received: by 2002:a0c:db8c:: with SMTP id m12mr6556035qvk.11.1607102438252; Fri, 04 Dec 2020 09:20:38 -0800 (PST)
Received: from [192.168.4.70] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id p12sm5139950qkp.88.2020.12.04.09.20.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 09:20:37 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <DM6PR14MB317843CA2B3D67F6660F4F0DD7F10@DM6PR14MB3178.namprd14.prod.outlook.com>
Date: Fri, 4 Dec 2020 12:20:35 -0500
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "BRUNGARD, DEBORAH A" <db3546@att.com>, Rob Sayre <sayrer@gmail.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Watson Ladd <watsonbladd@gmail.com>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "draft-ietf-tls-oldversions-deprecate@ietf.org" <draft-ietf-tls-oldversions-deprecate@ietf.org>, "STARK, BARBARA H" <bs7652@att.com>, "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com>
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <SN6PR02MB4512B95842251AE4C04B199CC3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <BYAPR14MB31765FD24F4DFD90F81AEE2BD7F30@BYAPR14MB3176.namprd14.prod.outlook.com> <SN6PR02MB4512CBA9E4BF6AAC778BC674C3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <DM6PR14MB31789349B737961728B7691ED7F30@DM6PR14MB3178.namprd14.prod.outlook.com> <CACsn0ckvoqZ5-JPRkOXp2Mw2zeTOdyCYLvX1NV1waJ-yidTwMQ@mail.gmail.com> <SN6PR02MB45129E647485BA5794D5CF4EC3F20@SN6PR02MB4512.namprd02.prod.outlook.com> <MWHPR02MB2464CD5D5B7568E9EAC58B26D6F20@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178EC0521427BF7C3523CACD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <CAChr6SzvQK+exfgYEwfVNknMjr-Y-UJ4A7k0DkOkL9wmLQ84aQ@mail.gmail.com> <MWHPR02MB246499F35613820D45EB55AAD6F10@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178A0C152A746E41C6A01C6D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <f8486514-9726-68d0-2bc8-dccd4293017e@cs.tcd.ie> <DM6PR14MB317843CA2B3D67F6660F4F0DD7F10@DM6PR14MB3178.namprd14.prod.outlook.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kN8Nqj0GTV6uBGAKQwLC0zW3PJw>
Subject: Re: [TLS] [Last-Call] 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: Fri, 04 Dec 2020 17:20:42 -0000

Michael, fundamentally the disconnect here seems to be that the IETF could ever be responsible for helping businesses to figure out how to plan for changes in technology _other_ than by doing work like this. Deprecating old versions of protocols is exactly what the IETF should be doing. This is how the signal burbles up through your vendors to you.

I think it’s useful for folks from enterprises to show up and pay attention to this, but it’s important to recognize that the reason we are making these changes is not to cause you trouble. It’s to try to help you to avoid trouble. If you come to the IETF with the goal in mind to get us to not deprecate protocols that are obsolete and have known attacks that the newer version of the protocol fixes, that’s just not the right model. We aren’t the adversary here. The IETF is not causing the protocol to be obsolete. The IETF is simply observing that the protocol is in fact obsolete, and it’s past time to stop using it. That is, we are observing a fait accompli over which we have no control.

The reason we do this is in the hope that you will do what you need to do to protect your customers from this fait accompli. The only thing that we could do differently is to not try to alert you to this problem.

When it takes twelve years for (some) enterprises to upgrade to the new version of a protocol, that’s an indication of some kind of systemic problem. It’s not a problem the IETF can solve. What I heard you saying at the beginning of this problem was that the IETF needed to understand your operational realities. But the implication is that we don’t understand your operational realities. That’s not what’s going on here. What’s going on here is that we simply can’t do anything about your operational realities.

The fact that we can’t do anything about them does not mean that TLS 1.1 shouldn’t be deprecated. It just means that you, not the IETF, need to take the next step: now that we have told you TLS 1.1 is so obsolete that nobody should be using it anymore, you need to integrate that into your planning. You need to communicate with your vendors. You need to budget for whatever your plan of action is going to be. If you find yourself in an untenable situation because of this, you need to learn from that and change your planning methodology so that you aren’t caught up short next time a protocol needs to be obsoleted.

Don’t do business with vendors who do not have a plan for how to deal with this problem. Get it in the purchasing agreements. Get it in the service provider contracts. Begin planning your transition to the new protocol the day it’s published, or ideally as soon as you become aware that it’s going to be published. Don’t wait until we publish a document twelve years later saying that it’s now officially obsolete.

This is a very important problem, and I’m sorry if my previous note made it seem like I don’t take it seriously. I do. But it’s not a problem that the IETF can solve. If the IETF were to decide not to say that the protocol is obsolete, that wouldn’t solve it.  You have the problem whether we tell you you have the problem or not.