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 20:11 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 349893A0F02 for <tls@ietfa.amsl.com>; Fri, 4 Dec 2020 12:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 XrU_EQouuzXh for <tls@ietfa.amsl.com>; Fri, 4 Dec 2020 12:11:21 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 619F53A0F48 for <tls@ietf.org>; Fri, 4 Dec 2020 12:11:21 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id q5so6624768qkc.12 for <tls@ietf.org>; Fri, 04 Dec 2020 12:11:21 -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=QlWHVwrP1t0os9Tr8n+XOeIyEZuE8EnkbUz8XiyPRnY=; b=s4gP84ukF43xu62OUm8ay7frvZ9W2zAO07b9cXKel7j3PPTLmW7Ga0dhRJyY6PNs3W mmnAVV5eNiJ8MRxtMVDdtb/1iK9oUx8AxFk2BAfncpopkO3oLHctkvvXNm5uNOMYmNJc hrvF9D8xE5N0Ku6/p/9DifX46/Q4eC52XR/UvL2klPAaw1i9fNRttl/DzNMwS4Kq8vHK r/igzIKRqRbq3OfVos/4NA7l5OLcwHXb9kEDF7BTqf/JrLfarp+Iynfjn3S9klkEx/Kg ij5kN9npgMzZSOlG+RTGRLP1y7bZcNN8BvuXEvYNeudFv6+lVb6CFGMZ3QvO9kjj2xom KZAQ==
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=QlWHVwrP1t0os9Tr8n+XOeIyEZuE8EnkbUz8XiyPRnY=; b=YnDj6X6dINpUqy/vaRHB5kCxA/eqZTenLlFOGaRBziBwEgDtXeTTmDm/OQi5WK0jVe 16XSiu+6+DChxq7Fxsiv12dJCLdrn+kCeRu5kPNPYZnImHQ5KCv79dg/bL0TfNACWooG n2tWg7LAWzyZhFkj43OZ0MyE3q8VTH6LjHKz8EQEUajiTdHJVJE2CRp5HKi39ej+FqO/ ZJXleIYDyJviEexgkLhPRHQfDOe7ANLi9HAVI5b9l9HlqymCk6Smpl0F7GI6WK53HYVv 1tquRr6v8yv0lvAnMcoxtADPQ5GgS9lXNj2A+HPeCKX5qlrCr6ZKNbgL/4qfjuasP2pa R0ig==
X-Gm-Message-State: AOAM532YJgn3kOGIYJg2uvD0jD2XYjvYsBQBFylBH42cL9OP/43IHW1p jmehyLs5LfmISrTN5FGf3BhTcA==
X-Google-Smtp-Source: ABdhPJxnIhEqwABbzMwE8Odm60eIi8JHhh32TKkwGlyF+qBGnFgIameUH3nfc2YGimFCrSCF/WCACA==
X-Received: by 2002:a37:a14a:: with SMTP id k71mr10764111qke.33.1607112680049; Fri, 04 Dec 2020 12:11:20 -0800 (PST)
Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id h26sm5753908qkh.127.2020.12.04.12.11.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 12:11:18 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <DM6PR14MB3178C1F8B6E4FD6E9FD9C8C4D7F10@DM6PR14MB3178.namprd14.prod.outlook.com>
Date: Fri, 04 Dec 2020 15:11:17 -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: <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@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> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <DM6PR14MB3178C1F8B6E4FD6E9FD9C8C4D7F10@DM6PR14MB3178.namprd14.prod.outlook.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i7T4p0m7yqeOXVvWZ1gvt9MAWmY>
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 20:11:23 -0000

On Dec 4, 2020, at 3:00 PM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
> 1. Enterprises do not expect nor want IETF to be responsible for their planning for changes in technology.    But when IETF decides to change protocols or deprecate existing technology of any sort,  it would be beneficial to all if our needs were considered and we were aware of related developments, in an effective and timely fashion.       

So by this do you mean something like the ops doc Elliot just outlined? If so, we agree that this is at least in principle worth doing, although I don’t know if it’s practical.

> 2. No one at any enterprise I am aware even remotely thinks that IETF is making changes to cause us or anyone else trouble.   Not even sure why you would say this.    The IETF is not as well understood by enterprises as many of us would like,  but in no way is it considered a troublemaker, adversary or any of the other things you say below that would make us seem at odds.   This area of understanding and communication is another area I hope we can collectively improve, by getting enterprises more engaged,  in some fashion or another.  

I think you misunderstood what I was saying.

> 3. No one I am aware of is saying do not deprecate protocols that are obsolete..........    Not TLS or any others.    We understand and recognize this need and support it.    My comments in this thread were in regards to related timing and the realization that large organizations cannot always be as nimble as most of us technicians would like.   And to a small degree I described WHY most enterprises require more time for changes in many cases. 

This clarifies it a bit. TLS 1.1 was superseded by TLS 1.2 in 2008. This is the 12 years. The process of moving to TLS 1.2 should have started at least when the TLS 1.2 RFC was published, if not before. Not necessarily installing software updates, but there should have been a rollout plan with at most a five year horizon at that point. Clearly there was not; this is what I’m saying needs to change. The time to start planning is not when the protocol is declared "obsolete, do not implement." You should have completed your rollout of the new protocol by this milestone, _at the very latest_.

> 4.  I don't think I or anyone else has said such changes will take 12 years as you stated.   However, 1-2 is usually a base due to budget and planning cycles at large orgs. 

That’s quite a bit more aggressive than I recall you being in the past, which is good.

> 5. I appreciate your advice on which vendors to deal with and how, but I do not view this as a vendor issue and do not have any current issues with any vendors on any related issues.    But I do agree, as stated several times in this Email chain,  that I would like to see enterprise requirements and engagement much earlier on in IETF processes.    You mention 12 years once again referring to how late we are and I am again not sure where that comes from, but I very much hope for earlier on involvement, in the future. 

What I mean by vendor involvement is that if you have devices that can’t be upgrade, that’s a planning failure. I don’t say that to point fingers, I’m just saying “next time, don’t buy products like that.” Maybe that’s not your issue, but it’s definitely an issue for hospitals, where much of their essential equipment runs Windows 7 or earlier and can’t be upgraded. Expensive equipment, where Windows is a tiny part of the delivered solution. This is disastrous.

> 6. Once again, in NO way am I or anyone else saying that the IETF should back off and not say these protocols or any others are not obsolete, not problematic or should not be deprecated.     
> 
> I hope the above makes sense and clarifies much of what I was trying to say.     IMHO we have taken this as far as we can or should on this list topic,  but hopefully improving enterprise and IETF communication/involvement discussions can be continued on other lists or in other fashions, as has been suggested by Barbara and Deborah.    Assuming this occurs, and I hope it does,  I hope you can be involved, as you are a greatly respected member of the IETF community and could add a lot to that discussion.  

I think Elliot has probably done a better job of zeroing in on what you are asking for than anyone in this conversation. The one thing that I hear you saying that I still find problematic is that you think the timing of the deprecation is too soon. Am I correct in thinking that’s what I heard?