Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

Hubert Kario <> Wed, 23 March 2016 12:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BF5312DC77 for <>; Wed, 23 Mar 2016 05:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JmruXLQ4cXb4 for <>; Wed, 23 Mar 2016 05:12:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2FD512D6CA for <>; Wed, 23 Mar 2016 05:07:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 8DADE711CB; Wed, 23 Mar 2016 11:31:22 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u2NBVLSM012345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 07:31:22 -0400
From: Hubert Kario <>
Date: Wed, 23 Mar 2016 12:31:20 +0100
Message-ID: <>
User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2987836.N7LvKqy9iR"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Wed, 23 Mar 2016 11:31:22 +0000 (UTC)
Archived-At: <>
Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC
X-Mailman-Version: 2.1.17
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: Wed, 23 Mar 2016 12:13:02 -0000

On Wednesday 23 March 2016 00:38:13 Timothy Jackson wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE
> curves seemingly without regard to the cipher suite strength. Thus,
> they'll select an AES256 cipher suite (e.g.
> TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key
> on the P256 curve. This seems odd to me, since the P256 curve
> obviously has a lower security strength than AES256. This seems
> important issue to resolve because most products (and even TLS
> libraries) do not allow the administrator to configure the available
> ECDHE curves, only the cipher suites. Thus, ECDHE may be invisibly
> undermining the security of your TLS connection.

In my experience, many (12%) servers simply ignore the list of curves 
advertised by client and use the P-256 curve always.

Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 
is not advertised.

> Is this an intentional choice by this group for some reason that I
> haven’t realized yet?

IMHO, it's just a result of limitation in the libraries - i.e. closer to 
"a bug" than "design choice"
> How would this group feel about a proposal to address this by
> specifying in the 1.3 specification that implementations must ensure
> that the strength of the certificate must be >= strength of ECDHE/DHE
> >= strength of the cipher? Perhaps an equivalency rule for the MAC
> might also be in order? Apologies if this is already resolved
> somewhere in the draft RFC. I looked but didn’t find it.

Recommendation? maybe. Requirement? unneeded if not harmful, for the 
points already raised
> For what it’s worth, I’ve noticed OpenSSL and other implementations
> trying to address this by creating a “Suite B Mode”, but that seems
> to address a specific case but leave the generic case unresolved.

Only the new OpenSSL actually can use more than one curve on the server 

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic