Re: [TLS] ban more old crap

Viktor Dukhovni <> Sat, 25 July 2015 05:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 128A21B2B73 for <>; Fri, 24 Jul 2015 22:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pFMNpEmQe15H for <>; Fri, 24 Jul 2015 22:46:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FAFA1B2B72 for <>; Fri, 24 Jul 2015 22:46:23 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 91496284B64; Sat, 25 Jul 2015 05:46:22 +0000 (UTC)
Date: Sat, 25 Jul 2015 05:46:22 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] ban more old crap
X-Mailman-Version: 2.1.15
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: Sat, 25 Jul 2015 05:46:25 -0000

On Fri, Jul 24, 2015 at 02:03:13PM -0400, Dave Garrett wrote:

> > and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to-
> > TLS1.3?
> TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3
> only. A TLS 1.0-1.2 client, or at least one offering that, is what it
> would not complain about.

We can probably put the "export" ciphersuite issue out of its
misery, already in email, these are no longer seen on the public
Internet.  The latest official versions of all supported Postfix
releases now turn off "export" ciphers (and also single-DES) by
default.  We've also by default turned off SSLv2 and SSLv3 (neither
are needed for SMTP interoperability).

What we've cannot yet turn off is RC4.  That's still sufficiently
widely used that disabling RC4 would result in excessive cleartext
fallback and even in some cases failure to deliver email.

So for opportunistic TLS (in SMTP) we've raised the bar to exclude
deprecated TLS features that we can (finally) easily do without.

I hope, that by ~2017, RC4 will no longer be required either, and
we'll be able to disable RC4 in Postfix at that time.

If I recall correctly, the upcoming OpenSSL 1.1.0 release will by
default also compile with no "export" ciphers, SSLv2 or SSLv3

We're starting to leave some of the older cruft behind.  Let's get
Chacha20 widely deployed (for systems without hardware AES), and
the passage of time lead to more RC4-only systems being replaced,
and in the not too distant future, even opportunistic TLS clients
should be able to forgo RC4, but we're not quite there yet today.