Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 26 April 2019 21:28 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 626F312060C for <tls@ietfa.amsl.com>; Fri, 26 Apr 2019 14:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jzD2b1a3GnSR for <tls@ietfa.amsl.com>; Fri, 26 Apr 2019 14:28:40 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763D0120611 for <tls@ietf.org>; Fri, 26 Apr 2019 14:28:40 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id B0C362B025B for <tls@ietf.org>; Fri, 26 Apr 2019 17:28:39 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com>
Date: Fri, 26 Apr 2019 17:28:39 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: IETF TLS WG <tls@ietf.org>
Message-Id: <D08B793B-3FE2-48A1-8ADD-C55C47300683@dukhovni.org>
References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <CADZyTkkJ63uq-Uukp00XAn+vFs6JtsNXF7stK=wbJpOvNBSs9g@mail.gmail.com> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com>
To: IETF TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ed_yYJPuTU-bTPC5C6f7qG8jsxg>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
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, 26 Apr 2019 21:28:54 -0000

> On Apr 26, 2019, at 11:24 AM, Salz, Rich <rsalz@akamai.com> wrote:
> 
> If they haven’t already moved off TLS 1 then maybe this document will give the right people a push to do so.
>  
> Nobody is going to arrest an MTA for non compliance.

Of course.

And as I said, I'd like to see the document move forward, I just
wanted to see whether there was any appetite for adding some
operator guidance.  It's not an issue of internet policing,
rather it is a question of whether there should advice for
operators who are considering disabling the legacy protocols.

The sound-bite version is: first raise the ceiling, *then* the floor.

The advice would therefore be for everyone to first make sure that
their systems support at least TLS 1.2, and not just the now deprecated
versions.  And then check whether the same holds true for their application
ecosystem and if so disable the protocols at that time.

In unauthenticated opportunistic TLS where cleartext is used when TLS
handshakes fail, removing support for TLS 1.0 can reduce security in the
short term (some messages needlessly going in cleartext).  Yes, this may
be what it takes to finally get the long tail procrastinators to upgrade.

The operational question then boils down to timing: when is your application
ecosystem ready to drop the training wheels.

Anyway, it does not look like there's much interest in adding operational
considerations, which users will then perhaps learn about elsewhere if
need be.  That's fine...

-- 
	Viktor.