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> Wed, 02 December 2020 16:00 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 772183A1578 for <tls@ietfa.amsl.com>; Wed, 2 Dec 2020 08:00:16 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 ATw4YpxZeWhG for <tls@ietfa.amsl.com>; Wed, 2 Dec 2020 08:00:14 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 0E9843A1540 for <tls@ietf.org>; Wed, 2 Dec 2020 08:00:11 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id z3so1346323qtw.9 for <tls@ietf.org>; Wed, 02 Dec 2020 08:00:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Aylv4No5GS17S16yUfLaBmxrYt9mfE2fDSu+OvzdPb0=; b=Q/cdqWX4mo7vNjocW/K73Hha1S333td9l97hUPrRmr4XZb/CjUw7bPvP1MC4HfCyL0 dmX+aCyntZRu+Q7JISXOW0UsXmvIDph5vI3bK/o6kEKh+fVC90p0vf7QN/Mndvr0CosE mH+mQwkfeUTjAIFEYMZMrGarr2ABDQYSxulbmmeyw1HVJQzO+V5m/L03ul76ZVjFw3zb i66j91gQ5OxZsQNEkSQ0RxaoXFYmwJP6+RBC/nA+Fs4HwJ8V89Hx6cRZBm9AbPGygzhf gmpuKzIN2XUuf6gamtEvqzmWHKI9qJCbvi9i3pnL/F1L1akPnXWUaCb5p9mu+XcYHUfC IEKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Aylv4No5GS17S16yUfLaBmxrYt9mfE2fDSu+OvzdPb0=; b=MhA1ETaodrXIJyhJyFhj3+dJ6K879PqBD8gdRft9Fp6ZyYrxynN2JW9mGtxr9k319D oA2PdOukjC6vYUHCO9OJ7WEDKswcMLhtUuAr8PazoigdQNx32yoT0FAZ+OUby1qcSCRb 09fbuztnPiusuAnpAL4CezOyZa7mPIKLPD+xDshr9O3ayWRgPpKH2ZIqIsu8mK9ZvuUD tcS2+gwJgOcKlx5YTLLlpUoumdsOTzNanfc++pt+SCcZK1Idsz0B6RfKxTJogukFtMYj YZ4liNUvzJAhGxST2qKVPnBW7WilxXVi3Nwizhyg0aawBpEF8tT9tM1qcLmjyW0UEpX9 O57A==
X-Gm-Message-State: AOAM533IbqoChsRbULo6BxCnovqvfr5P8na0sDmehHNapkkVX0Uz8yRG slBw2cCxdACa8DIhEhM48tEhNg==
X-Google-Smtp-Source: ABdhPJyPruA2CSxHLbCT0ZFOXIhKnpaxSQJl4m8dUWe/Fi/dVMexBnXHFUWnHO47362/aVpT3r+R9w==
X-Received: by 2002:aed:3a47:: with SMTP id n65mr3284980qte.182.1606924810897; Wed, 02 Dec 2020 08:00:10 -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 a3sm2026307qtp.63.2020.12.02.08.00.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 08:00:10 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <B70C09E7-3FB2-41A6-AFEC-2EC0EB00DA97@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F367FC9-2EE3-4E97-B653-CD1B73FEC356"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Wed, 2 Dec 2020 11:00:08 -0500
In-Reply-To: <BYAPR14MB31763782200348F502A70DA4D7F30@BYAPR14MB3176.namprd14.prod.outlook.com>
Cc: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, "draft-ietf-tls-oldversions-deprecate@ietf.org" <draft-ietf-tls-oldversions-deprecate@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "STARK, BARBARA H" <bs7652@att.com>, "tls@ietf.org" <tls@ietf.org>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
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> <0b72b2aa-73b6-1916-87be-d83e9d0ebd09@cs.tcd.ie> <1606814941532.76373@cs.auckland.ac.nz> <36C74BF4-FF8A-4E79-B4C8-8A03BEE94FCE@cisco.com> <SN6PR02MB4512D55EC7F4EB00F5338631C3F40@SN6PR02MB4512.namprd02.prod.outlook.com> <1606905858825.10547@cs.auckland.ac.nz> <EEFAB41B-1307-4596-8A2E-11BF8C1A2330@cisco.com> <BYAPR14MB31763782200348F502A70DA4D7F30@BYAPR14MB3176.namprd14.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/w2KpzYM_Sj_j9mS1YBaPTLYXbmM>
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: Wed, 02 Dec 2020 16:00:24 -0000

On Dec 2, 2020, at 9:58 AM, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
> As an Enterprise person I can say we are not well equipped to be aware of nor react "Nimbly" to changes such as this.  Wide scope and security related changes can require major changes to core Business systems.  This can mean significant time, effort and/or $$$. 
> The biggest barrier is that this topic is not currently on the Planning or Budget radar at all, and usually takes 1-2 years (or more) to achieve either. 
> 
> On one side of such issues, I don't think IETF understands the above and on the other side Enterprises are unaware of developments at IETF and other SDO's.    Bridging that important gap is not unique to this topic. 

It’s important not to catastrophize this. The IETF understands perfectly well how this process works. We write and publish RFCs, and industry (we hope!) follows. It’s a pipeline: an event happens in the IETF, it trickles out through your service providers and network product vendors, and ultimately, at some time usually quite long after the RFC is published, you have to take action.

The situation right now is that it’s been known for a long time that RC4 and MD5 are not safe to use. Your vendors have known about this for a long time. If they do not have a roll-out plan for software that corrects the problem, you have chosen the wrong vendors. Look at your agreements with them. Are they honoring them? If not, you have recourse. If you didn’t contract with them to anticipate change, it’s time to go fix that.

Stop pretending that we live in a world where we can ignore advances in technology. We don’t. If your current plans don’t assume that every bit of tech gear you have in every rack in every machine room and every hospital room will have to be upgraded at least every five years or so, hopefully in software, then change your plans now. Stop arguing with us and go do that.

Because even if browser vendors don’t follow this change quickly, you can be sure that malware writers will. Hospital after hospital keeps getting taken down with the same malware. Lives are on the line. People have died because of this.

You should be working to fix that, not trying to get us to stop asking you to fix it.