Re: [TLS] ban more old crap

Yuhong Bao <> Fri, 24 July 2015 18:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 937B21ACD13 for <>; Fri, 24 Jul 2015 11:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BwOhGDyNm6xq for <>; Fri, 24 Jul 2015 11:14:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9833F1ACC85 for <>; Fri, 24 Jul 2015 11:14:15 -0700 (PDT)
Received: from BLU177-W51 ([]) by over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 24 Jul 2015 11:13:49 -0700
X-TMN: [alusQMfAT0QkhD72dS3viNrs0qK8cjcD]
X-Originating-Email: []
Message-ID: <BLU177-W5155C38D58E02217B59866C3810@phx.gbl>
From: Yuhong Bao <>
To: Dave Garrett <>, Hubert Kario <>
Date: Fri, 24 Jul 2015 11:13:41 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>, <>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Jul 2015 18:13:50.0844 (UTC) FILETIME=[7E068BC0:01D0C63C]
Archived-At: <>
Cc: "" <>
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: Fri, 24 Jul 2015 18:14:19 -0000

> On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote:
>> On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
>>> To be clear, the wording I have in the PR is not this broad. It only
>>> requires aborting if export ciphers were offered by a TLS 1.3+ client, not
>>> just any client.
>> 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.
> For the rare case of "legitimate" use of export ciphers, namely spiders, it'll need a fallback attempt with a full set of suites. Export ciphers are not something we should be accounting for allowance of in any protocol we want to claim to be secure.
> We do have to remember that even _offering_ them is dangerous, even if they're not negotiated. It's dangerous to even _support_ them, even if not offering. Having this in any way presents an unacceptable attack surface for a MitM to try and find a way to confuse implementations into using them. If all implementations were perfect, yeah, this wouldn't be a problem. History has shown this is not the case. :(

Personally, I don't think this is worth the effort. You'd need a full list of EXPORT cipher hardcoded, and there are also EXPORT1024 ciphers not in the cipher suite registry but less dangerous. It is rare for current TLS 1.2 clients to offer export ciphers either, and most practical attacks are prevented by disabling them on the server side.