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

Viktor Dukhovni <> Tue, 01 December 2020 04:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F07D3A0147 for <>; Mon, 30 Nov 2020 20:11:47 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H5QU6FUEHpSx for <>; Mon, 30 Nov 2020 20:11:45 -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 A31EF3A00D9 for <>; Mon, 30 Nov 2020 20:11:45 -0800 (PST)
Received: by (Postfix, from userid 1001) id CED211B7BCE; Mon, 30 Nov 2020 23:11:44 -0500 (EST)
Date: Mon, 30 Nov 2020 23:11:44 -0500
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] 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: Tue, 01 Dec 2020 04:11:47 -0000

On Mon, Nov 30, 2020 at 07:40:34PM -0500, Keith Moore wrote:

> I've been thinking something like this also.  But IMO there are still 
> valid cases for negotiating older versions of TLS on the public 
> Internet, such as the mail relaying case mentioned earlier.    So far I 
> haven't thought of a reason where either (a) bouncing an email message; 
> (b) resending it in cleartext; or (c) discarding it, is better than 
> relaying with TLS 1.0 or 1.1. (Though maybe there aren't enough MTAs 
> that do opportunistic TLS using version <= 1.1 to matter.)

For lack of any known substantive downgrade attacks against STARTTLS in
SMTP relay from TLS 1.2 to TLS 1.0, I've no immediate plans to disable
default support for TLS 1.0 in Postfix.  For opportunistic TLS the
effect of that would be to send in cleartext rather TLS 1.0, which seems
unnecessary at present.

SMTP servers that support DANE have been steadily moving away from TLS
1.0, but these are presumably operated by folks who pay extra attention
to security, and are not representative of the long tail of folks who
leave "well enough" alone.  My most negotiated TLS version stats for
SMTP servers supporting DANE are:

   TLS 1.3: 9064
   TLS 1.2: 7239
   TLS 1.1:    0
   TLS 1.0:   27

Two years ago, they were:

    TLS 1.3:  204
    TLS 1.2: 3561
    TLS 1.1:    2
    TLS 1.0:   35

The trend is definitely towards TLS 1.3, and away from TLS 1.0, but
the long tail takes time to fade away.

So at some point it might make sense to disable TLS 1.0 support by
default, and some users are choosing to do it early by overriding the
defaults, but I am not convinced the pros outweight the cons today.