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

Gary Gapinski <> Thu, 03 December 2020 02:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE7633A08A9 for <>; Wed, 2 Dec 2020 18:33:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d64Z7H7lZSdm for <>; Wed, 2 Dec 2020 18:33:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D788B3A08BB for <>; Wed, 2 Dec 2020 18:33:43 -0800 (PST)
Received: (qmail 25207 invoked by uid 503); 3 Dec 2020 02:33:41 -0000
Received: from unknown (HELO ( by with ESMTPA; 3 Dec 2020 02:33:41 -0000
To: "Ackermann, Michael" <>, "STARK, BARBARA H" <>, 'Eliot Lear' <>, 'Peter Gutmann' <>
Cc: "''" <>, "''" <>, "''" <>, "''" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Gary Gapinski <>
Message-ID: <>
Date: Wed, 2 Dec 2020 21:33:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------08A217B0A05FB41F9728AC8A"
Content-Language: en-US
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2020 02:33:46 -0000

On 12/2/20 6:00 PM, Ackermann, Michael wrote:
> 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.....

RFC 2119 equates, semantically, at least in English, MUST NOT with 
prohibition (_not_ deprecation).

draft-ietf-tls-oldversions-deprecate-09.txt uses MUST NOT in §4 and §5.

It does use the term "Deprecation": prominently, and likely inadvisedly, 
in §2. Re-worded, the title of §2 should be "Support for Prohibition" 
(particularly as its prior sibling is §1.2 "Terminology", which is 
inescapable boiler-plate and likely is invisible to any RFC readers).

I cannot resist citing H. L. Mencken's definition of Puritanism here.

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

Perhaps such lack of awareness could be considered as the difference 
between (Aquinian) vincible and invincible ignorance.

Whether such is a mortal or venial sin, or no sin at all, could be 
considered in light of risk evaluation and management. Or one's 
tolerance for the wages of sin. Steely determination for continued use 
of flawed protocols can be admired while simultaneously lamented.

In other words, is a _prohibition_ (à la, e.g., PCI DSS) of TLS versions 
prior to TLS 1.2 (and prior to 1.3 for that matter) sufficient to demand 
upside-down crucifixion for failure to comply, or something more 
family-oriented. In either case, perhaps an appendix expressing the 
tension between prohibition and tolerance might suffice, rather than 
watering down §4 and §5. But such an appendix would be necessary in any 
normative RFC, so, in my opinion, the draft can be published without 
such an appendix.