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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 04 December 2020 00:54 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 F12DD3A10F2; Thu, 3 Dec 2020 16:54:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 OZrJBE66gg5Z; Thu, 3 Dec 2020 16:54:31 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C333A0E59; Thu, 3 Dec 2020 16:54:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 232EBBE2C; Fri, 4 Dec 2020 00:54:29 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRrdIYMy7EJC; Fri, 4 Dec 2020 00:54:27 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3363ABE24; Fri, 4 Dec 2020 00:54:27 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1607043267; bh=CFx5p564R+Lcc+Jte6QgzsTLn3ICJxGPTzpkgrcsN/c=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=nOxgMsXn7U+Yj/EwLHu3Sm+3vafFEbf5DQZl/VznT5xLR0SNuicO5gx0bInxpY8vH myq1oGAN3UixE1Smv7KhGfWeLa9in6mKf4apzH/yKKbs84QuR9TSaOIliAC4ssJWuE sn0MjooqQBSSBiZS1sjiwHJ8FU3WRf2iVDVUw3vk=
To: Rob Sayre <sayrer@gmail.com>, "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: 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>
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <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> <CACsn0ckvoqZ5-JPRkOXp2Mw2zeTOdyCYLvX1NV1waJ-yidTwMQ@mail.gmail.com> <SN6PR02MB45129E647485BA5794D5CF4EC3F20@SN6PR02MB4512.namprd02.prod.outlook.com> <DM6PR14MB3178A08C84E01A8DCB0711A0D7F20@DM6PR14MB3178.namprd14.prod.outlook.com> <CAChr6SzHH7Q8VcbRxMF8s2comf_pdew4Af9=FODvTNfaaTmdgg@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <7c4750e8-a3d6-dadd-b854-9ac5785c2938@cs.tcd.ie>
Date: Fri, 04 Dec 2020 00:54:25 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CAChr6SzHH7Q8VcbRxMF8s2comf_pdew4Af9=FODvTNfaaTmdgg@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="KwYvgihZmjpaJw2D93rWRTnlwgYNRuNj5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TsD90J8Ga6Tu9NyIpIlAvdI5CPc>
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 00:54:33 -0000

(Even though this sub-thread has no effect on the draft, I
couldn't resist:-)

On 03/12/2020 23:53, Rob Sayre wrote:
>> The enterprise perspective is not usually considered or understood at IETF
>>
> I think that perspective is both considered and understood, but not usually
> accommodated.

I think you're both wrong:-)

It seems wrong to me to assume that there is a singular
and united "enterprise perspective" on TLS and that was
very clear from earlier debates where some people made
one kind of assertion, while others, also correctly saying
they represented "enterprises" fully disagreed.

There are of course a set of networks that have difficulty
in managing and updating the systems that make up their
networks. There are others for whom updating TLS is going
to be much less of an issue due to the nature of those
networks (newer, or more automated/centralised, or whatever).
Both situations arise for understandable valid reasons but
dealing with the cases where problems do or don't arise
isn't helped IMO by over-claiming on any side.

And yes, in addition to the above, there are people whose
main (and also reasonable) concern is the web, and their
concerns and ability to handle updates do differ. And
there are others for whom other issues take precedence.

None of that means a lack of consideration, nor a lack
of accommodation. For things like TLS, where code is
often delivered via libraries, the timing of change does
sometimes make for awkward compromises, that will make
some of the above unhappy, but that's just life and is
why the WG chairs and ADs are such well paid consensus
callers:-)

I think the IETF process works pretty well for all this,
overall, and over time.

Cheers,
S.