Re: [TLS] ban more old crap

Hubert Kario <hkario@redhat.com> Fri, 24 July 2015 10:43 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982081A8AC8 for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 03:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kT3y_yhPGlm for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 03:43:25 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4331A8AA6 for <tls@ietf.org>; Fri, 24 Jul 2015 03:43:25 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 200ADC03F9; Fri, 24 Jul 2015 10:43:25 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-111.brq.redhat.com [10.34.0.111]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6OAhMPG029704 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 06:43:24 -0400
From: Hubert Kario <hkario@redhat.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Fri, 24 Jul 2015 12:43:17 +0200
Message-ID: <2433298.8v8VhukdnX@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <201507231421.15927.davemgarrett@gmail.com>
References: <201507221610.27729.davemgarrett@gmail.com> <CABcZeBMbuqKwK2T1e0jHOE6+SJRViBZAny_2Bo5x-eDTp_-b9g@mail.gmail.com> <201507231421.15927.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart19973229.HYUFYfiIF4"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qmeAKnBz6mWQcYAtk2Q4GV7cin8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ban more old crap
X-BeenThere: tls@ietf.org
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." <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, 24 Jul 2015 10:43:27 -0000

On Thursday 23 July 2015 14:21:15 Dave Garrett wrote:
> On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote:
> > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> > <stephen.farrell@cs.tcd.ie>> 
> > wrote:
> > > A suggestion - could we remove mention of anything that
> > > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > > and then have someone write a separate draft that adds a
> > > column to the registry where we can mark old crap as
> > > deprecated?
> > 
> > I'm starting to lean towards this. I don't generally think of TLS 1.3 as a
> > vehicle for telling people how to configure use of TLS 1.2, and I think
> > it might be better to move all that stuff out.
> 
> If we've learned one thing from the past year of high-profile
> vulnerabilities with names and logos, it's that TLS is not really secure if
> you don't take into account its weakest/oldest feature that's still
> possible. I don't think any responsible TLS 1.3 spec can afford to not
> acknowledge this.

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.

The way to remove all this legacy junk is to work towards sensible defaults in 
libraries (RFC7568, RFC7465 style), not by putting antifeatures in protocol 
specifications.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic