Re: [TLS] ban more old crap

Hubert Kario <> Fri, 24 July 2015 17:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D08B1A1AD9 for <>; Fri, 24 Jul 2015 10:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9jhitBkVNNeS for <>; Fri, 24 Jul 2015 10:28:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CB311A1A7D for <>; Fri, 24 Jul 2015 10:28:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id AC7C92E1238; Fri, 24 Jul 2015 17:18:48 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t6OHIkh6024023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 13:18:47 -0400
From: Hubert Kario <>
To: Dave Garrett <>
Date: Fri, 24 Jul 2015 19:18:41 +0200
Message-ID: <>
User-Agent: KMail/4.14.9 (Linux/4.0.8-300.fc22.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2888615.WXAVBIlkHJ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
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 17:28:19 -0000

On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
> On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote:
> > And I completely agree. FREAK and Logjam wouldn't happen at all if we
> > didn't drag with us stuff that was considered legacy 10 years ago.
> > 
> > But stuff like "server MUST abort handshake if it sees export grade
> > ciphers in Client Hello" (or anything similar) will just get ignored. For
> > a user a bad connection is better than no connection. One works and the
> > other doesn't, the details are voodoo witchcraft.
> 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-

> The point is to ensure that all TLS 1.3 implementations
> cut this out and don't regress due to error or exploit. Applying it to
> everything would, unfortunately, be a mess. In particular, search engine
> spiders actually have a legitimate reason to have export ciphers actually
> still enabled.

and not only them, opportunistic encryption in SMTP is another example

technically it's already in the draft, isn't it? - TLSv1.3 supports only AEAD, 
all export ciphers were either CBC or stream mode - if you intend to accept 
only TLS1.3 reply from server there's no point in including them, moreover 
negotiating them is a clear bug and protocol violation anyway

but if you want a "clients SHOULD NOT advertise support for ciphersuites 
incompatible with TLS1.3 if it will not accept a TLS1.2 or lower protocol 
reply from server" as a reminder/idea for implementers then it certainly won't 
Hubert Kario
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic