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

Watson Ladd <watsonbladd@gmail.com> Thu, 03 December 2020 15:23 UTC

Return-Path: <watsonbladd@gmail.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 80C303A0E2A; Thu, 3 Dec 2020 07:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uokCoDjIy9PD; Thu, 3 Dec 2020 07:23:34 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 697D53A0E30; Thu, 3 Dec 2020 07:23:28 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id o24so2944097ljj.6; Thu, 03 Dec 2020 07:23:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HG82s04gkT4qjqsdGoqWrSAmfeKroRcO7O9y5/rYZKM=; b=SK1Mtf5uF3e9LVoOHHYcakpXPbXAqQjkVrwNDY7iQYwVIUbulqCS/hldTjN9gXIIY3 w6HlBIPiEs9ShVED0bPi6pZGnwIe6OYoylWNxZzignnq2+Et9Cavw4+59X0p5yB8dnkI tS4sdCFMIeR35rR6qWPdy6fMtwsLJeSfHT6QqmIXkOgRS/7pl8EDMwf9ggcpTNuv9Ca6 ycsSqYWE76KFByKquJ9YGqzP3H79DrSIgi2yghtJlk3BQNbzbtC8Jg0Rc12wc9/n55A3 S5qcOnSIxtJmQp2vf7DPy/rv9GiyeqrXj3WYm2Gk0+JltA47LWMuRx/3vY6yv6XCQj4C LugA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HG82s04gkT4qjqsdGoqWrSAmfeKroRcO7O9y5/rYZKM=; b=HeCxmmQBDvBi9rNmHHz4w6uu5+guzNBsYPpULaZ9OqY/O4xapameTZIKMRdwpVacBN uSpY2c82cOvjtOu5F2YL45EK4Y3GuNE86fZVbPgZPk9Q5djQ0wMKOmsq0Dy40naoS+2X GUre/yjTSw5LP/aa228gNKI8HbQhvMVDpBq9XblyGFXaZOvEWBgCw85iH9o0yt1vNenl z1wdKIsnXBfYyQYvHOn3BzVjiSsjZYrpNWLRJ5Y6wEfwK9lYcKTyJ633kh+eWQfuKp2F uf6VQT5FMuNy85rhbYBz61UoYaliqQasG2k9kNcmNftkQDnVd5nesDpRvOmR3rMf9o93 FDtQ==
X-Gm-Message-State: AOAM533LDDTeIx1lG46xXqXSLM+2TFumqBo6tZt7m8KRRxdQE9dZbevi ab2oK2gjOJRViTps3fo56rRnrmuY47KfKLrRl7gVuTcPnfQ=
X-Google-Smtp-Source: ABdhPJzZyG49gO1t9pr6QKMSG3dZmabGReM1P41tIwgGB1/RHRuZ15LWTNhAny/hAaEv9dmbzAG1nU+H9iNVjDZiyZI=
X-Received: by 2002:a2e:b5d9:: with SMTP id g25mr1500326ljn.234.1607009006567; Thu, 03 Dec 2020 07:23:26 -0800 (PST)
MIME-Version: 1.0
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> <SN6PR02MB4512B95842251AE4C04B199CC3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <BYAPR14MB31765FD24F4DFD90F81AEE2BD7F30@BYAPR14MB3176.namprd14.prod.outlook.com> <SN6PR02MB4512CBA9E4BF6AAC778BC674C3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <DM6PR14MB31789349B737961728B7691ED7F30@DM6PR14MB3178.namprd14.prod.outlook.com>
In-Reply-To: <DM6PR14MB31789349B737961728B7691ED7F30@DM6PR14MB3178.namprd14.prod.outlook.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 3 Dec 2020 07:23:14 -0800
Message-ID: <CACsn0ckvoqZ5-JPRkOXp2Mw2zeTOdyCYLvX1NV1waJ-yidTwMQ@mail.gmail.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: "STARK, BARBARA H" <bs7652@att.com>, 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@ietf.org" <tls@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Kt39DNND7d17Q6y8ri0qnrTYphk>
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: Thu, 03 Dec 2020 15:23:38 -0000

On Wed, Dec 2, 2020, 3:18 PM Ackermann, Michael <MAckermann@bcbsm.com> wrote:
>
> Barbara,
> Thanks.
> And I think I was aware of all you state below regarding TLS, and apologize for any related confusion regarding IPv6, even though, for the purposes of my comment, they are similar.
>
>
> I don't disagree with anything you say on the TLS subject,  which is essentially that prior versions of TLS may be considered insecure, etc.  and should be deprecated.....

Shouldn't we publish a document saying that? It seems this would
represent consensus, even your view of the issue.

>
> My associated point is that Enterprises are generally not aware of this and that it is not currently on our Planning or Budget Radars.


TLS 1.2 has been around for how many years? All versions of OpenSSL
without support have been EOL for some time. How many other CVE remain
to be found in them? FIPS, PCI etc are all very clear that old TLS is
going away. Browsers have supported TLS 1.2 for years. So has Windows.
This depreciation should be easy given the extent of support for TLS
1.2.

I bet that most services you run are already using TLS 1.2 or even 1.3
because the client and server have been updated.

> Further, this means we are potentially years from effectively and operationally addressing such issues.

Let's be about it.

>    And we must do so in conjunction with Partners, Clouds, Clients and others.
> And my general, overall point is that the answer to addressing the above is to find way(s) of making Enterprises aware and possibly assisting with methods of addressing.     I think I also said this  problem is not unique to TLS or IPv6.      More, it is a lack of understanding of how things work within Enterprise Networks and the lack of Enterprise engagement in Standards Development processes.
> And finally, this may not be a gap that the IETF should care about or address, but someone should, IMHO.

Your argument against the current text seems to be the following: we
have a problem. It is inconvenient for me that you will ask me to deal
with the problem. Therefore I would like the problem to not be
acknowledged.

Perhaps I am being too uncharitable. But I fail to see how softening
the language eases depreciation, or what the consequence you fear
happening are. You're free to continue ignoring the RFC series. But
reality does not go away if it is ignored.

Sincerely,
Watson Ladd

>
> Thanks
>
> Mike