Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)

Hubert Kario <> Thu, 23 July 2015 17:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3CC651A895B for <>; Thu, 23 Jul 2015 10:18: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 F-6_eWGkgcZx for <>; Thu, 23 Jul 2015 10:18: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 557531A8957 for <>; Thu, 23 Jul 2015 10:18:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id B54DA2CD816; Thu, 23 Jul 2015 17:11:50 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t6NHBktT013841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2015 13:11:49 -0400
From: Hubert Kario <>
To: Dave Garrett <>
Date: Thu, 23 Jul 2015 19:11:38 +0200
Message-ID: <>
User-Agent: KMail/4.14.9 (Linux/4.0.8-200.fc21.x86_64; KDE/4.14.9; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart55302262.phjt5pjf2m"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)
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: Thu, 23 Jul 2015 17:18:19 -0000

On Thursday 23 July 2015 11:43:45 Dave Garrett wrote:
> On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> > vast swaths of web servers are misconfigured; introducing a more complex
> > mechanism to server configuration when the existing situation is
> > incomprehensible to many administrators won't help (and even many people
> > that write the various blog posts about "how to configure SSL [sic] in
> > httpd" clearly haven't read openssl ciphers(1) man page)
> We should just get more serious about banning old crap entirely to make
> dangerous misconfiguration impossible for TLS 1.3+ implementations.

there are valid use cases for both aNULL and eNULL
at the same time 3.5% of Alexa top 1 million will negotiate AECDH, somehow I 
doubt this many use it knowingly when ADH has just 0.2% market share

TLS is a universal protocol, that means that something that is a dangerous 
misconfiguration in one threat model is entirely valid and good configuration 
in other

IoT and cloud computing will create a market for an implementation that is 
compatible with many threat models

> Right now, the restrictions section prohibits:
> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available
> How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all
> TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or
> ECDHE for ALL connections, even back to TLS 1.0, or abort with a fatal
> error. (the wrench in this is plain PSK, which should be restricted to
> resumption within a short window; IoT people who want to use intentionally
> weak security can write their own known weak spec)

yes, it would make situation better, thing is, nobody would implement this and 
nobody would deploy it (certainly not Red Hat).
People care more for availability of data than for confidentiality or 

> By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be
> badly configured to only allow it with DSS, because missing combos from the
> cipher suite nonsense happen. If we actually have to care about IE on XP,
> we could state an exception that the only non-PFS cipher suite to be
> permitted on servers for backwards compatibility is

and that would prevent the server from never selecting DHE+RSA or client 
aborting the connection when server selects DHE+RSA how exactly?

> Also add a requirement that all config provided by the admin must be
> validated to meet the TLS 1.3 requirements and auto-corrected if not, with
> a warning if there's an issue.
> This doesn't have to be a mess for admins to sort out.

but it is, and for histerical reasons it will remain like this

so given choice I prefer my mess to be at least consistent between versions
Hubert Kario
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic