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

Kathleen Moriarty <> Sun, 06 December 2020 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE6603A0D45; Sun, 6 Dec 2020 04:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CAWMVgL5voKw; Sun, 6 Dec 2020 04:59:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7241E3A0D4B; Sun, 6 Dec 2020 04:59:05 -0800 (PST)
Received: by with SMTP id q22so10080557qkq.6; Sun, 06 Dec 2020 04:59:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=3pHIEBz2DRghOg5AW2K/NTCtwDKBb2Ln1DLpvCe5lqs=; b=nc5hxm5D0UcTg69JqkkdHE+6M8epsvX5oJlCWVks1MsmeqYP+94VjnXv1Z6D2fV7Zh tgyJA5pZ5zmErLpx+ZtABSFwcezS5ur4DcMnT+IbkErV02aBBn7vQi9/LRxYZK2gG5Y6 ntitysCU7SfyM/LFnss07XX8CrqFcnKxYTwfK0y5KyY2oW3sB5/4DYcvBXKPzTNChube IOWL5s3pUVNE2X1mK/qAeuAJ1zRN1rOuEXQ1T+WIGGmqZMzbgMpohXUWxIh5lS62mLlV Z1BGrSU7BiDKzev+NohOYB+akICjKLgf3eAWrqfZH60c7IBMJoRqXGJ5lHuF7pdo1y8t 1EwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=3pHIEBz2DRghOg5AW2K/NTCtwDKBb2Ln1DLpvCe5lqs=; b=g8Mr6e4l5DKYQnbqcmTDWMCoweDgP7NCkL+//JbbEzj5DFDd9IraBsFYcXWG8FIZoQ 5owjNpkpmnlvu+78nfEgO/DAeXOF5nAwCkQGu+bfr0zaSfK33rkmZZX1jKIXdzl4/IDs TgWWCbgygn9HlOVt2rqRgqlUy2N8iAeaZLWgja9orH3HzFQKI7h5s77AcXTQCpinAzZj MUg05xZVrOK/UG6YzYUfQHGypVRS9AbJaB+BLts7OsmY0T+CE65s7eAkMZTR3ahW0LEF 87cYQIyNmChRHECyECSHq+/GuQ6qVYK/FNcUKLH+quQC4lIFw+/WF7ompjY5vVZBbKXE p9pA==
X-Gm-Message-State: AOAM531KPpelAngGrLnh0yK7ZoM/6//Zpf/kYkTxo6krtcWu9cJ04qgg d6cWOkJfEeRDWZxCCJ3efvndG7/jXZc4Bg==
X-Google-Smtp-Source: ABdhPJw7LcjkVEHBkSBZwAkhes9Vyjlzt7czBEV8dizo8qlfEJMFz95Bj0VE8zSVR1z7ZvcHA+HVlw==
X-Received: by 2002:a37:4658:: with SMTP id t85mr18983662qka.210.1607259544103; Sun, 06 Dec 2020 04:59:04 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id v9sm9671197qkv.34.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 04:59:03 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Kathleen Moriarty <>
Mime-Version: 1.0 (1.0)
Date: Sun, 6 Dec 2020 07:59:02 -0500
Message-Id: <>
References: <>
Cc: Stephen Farrell <>, Keith Moore <>,,,,
In-Reply-To: <>
X-Mailer: iPhone Mail (18B92)
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: Sun, 06 Dec 2020 12:59:10 -0000

Having risk management experience as well as policy establishment and enforcement, I would rather see the clear notification that something is not secure.  Then the organization makes the decision to take that risk based on likelihood/impact considerations.  This factors in risk tolerance and business objectives.  I am an author on the draft, and don’t think this is the place for those business decisions to be made.

Best regards,

Sent from my mobile device

> On Dec 1, 2020, at 12:52 AM, Ben Smyth <> wrote:
> I haven't followed all the nuances of this discussion, but it seems to boil down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private enterprise running legacy kit, which makes decision makers anxious, since they don't want responsibility for something they "MUST NOT" do: A solution might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby allowing sectors to define their standards/principles/expectations. 
> _______________________________________________
> TLS mailing list