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

Dave Garrett <> Wed, 23 March 2016 03:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02A6612D576 for <>; Tue, 22 Mar 2016 20:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uRfdoZiIhgKr for <>; Tue, 22 Mar 2016 20:26:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18A2C12D157 for <>; Tue, 22 Mar 2016 20:26:26 -0700 (PDT)
Received: by with SMTP id y89so2613161qge.2 for <>; Tue, 22 Mar 2016 20:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=Pd76PVyb3+0bleZVXKMXD5W/yJ4Lv1lGPjrwwuJEaw0=; b=vwBZ3KOda8DunFwsHdEGCqj95CFO4GEHI18gCcAlc9FYiA2cExriMWm8eWy3cvCjmb lUoKBC52pHLSu5iz40EIbDKWegg6X4DPMV/1z47hv3YywEPy8PBaIsy29zZnXdk7tDQ1 CKz7i4RJcwexwh96a5hN9RwLyz0tZOwrHJ3ZeC+Kzy5aLWfln5ZF9RZ8ynw7DWNpNRKl YvwMzWI4mX0iYz+tnQ0eKt5yC1ndtc0dGFvjO4ziieVde8y5qpatWMn1JZswtpT/T1Jm M+mCcU+Dtoqg6UjsB5Zq3RkF5ICnNvyNXZq8Pz0gQVyP/7A4wWoTOKxGcOEaaz+Vb96J 7x0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=Pd76PVyb3+0bleZVXKMXD5W/yJ4Lv1lGPjrwwuJEaw0=; b=QryeZIGp9aOJF1c8EiHu+YPV7BjHTmymGFzV2hePgXyk59/HUgJYDMe5PlEWrbGSGj qjjgKlNYj+7JZUm3jJOGzOcFCgImqHm9xZtendc3katbpZNeX3GTqJX4DJdYvypYHIIo 4xDmCSvgVvrUHQrPKuZQ08Y+YTc6+SQAFZuECYWpAkqVFsPqXDp0Bw9+m8wDRiO4tVZ9 QPR84ilyaFuayAiudHNBA3Pc+6OS4YXqqK4PiURMjgaLpE1IBqp0j24L9Cw8MkXueLP5 PuRVMLZEoR0oz/9EZh/l87ox/QQaD/3wxyU2SzQB7mKnstAlYuZf/yoQdWwpQthj7PV6 kkzg==
X-Gm-Message-State: AD7BkJKBv3JL14lin9bOcZg+NdtXaXV44qkCH9q2X7RhubEtLjFLtbc1L9UiBONMnijqLA==
X-Received: by with SMTP id 14mr557692qhc.85.1458703585108; Tue, 22 Mar 2016 20:26:25 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id o67sm233245qho.12.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 22 Mar 2016 20:26:24 -0700 (PDT)
From: Dave Garrett <>
Date: Tue, 22 Mar 2016 23:26:22 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
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 03:26:28 -0000

On Tuesday, March 22, 2016 08:38:13 pm Timothy Jackson wrote:
> 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.

I've had a changeset sitting around for a while for recommendations (not hard requirements) to match the strengths for key exchange and bulk cipher key size. (it was leftover from a batch of other work, long since merged) That said, I'm not actually sure what my opinion is on this anymore. It's been on my todo list to bring up a discussion.

There's complications here that make picking a matching number less than straightforward:

1) A main reason to switch to 256-bit ciphers is for post-quantum crypto, but all (EC)DHE is completely broken in that scenario. Bigger numbers there won't help in any meaningful way.

2) Neither AES-256 nor ChaChaPoly match up things perfectly, already. For PRF, AES-256 uses SHA2-384, not SHA2-512; ChaChaPoly uses SHA2-256. AES-256 also has a 128-bit block size.

3) There's more to group security than bits. For a start:

At this time, I'm leaning towards sticking in a recommendation to prioritize the following groups, in this descending order:

X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then lastly, ffdhe8192 and/or secp521r1 only as emergency backup (arguably, X448 belongs back here too)

I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use for TLS 1.3+ and only support it for transition in older TLS. (this came up on-list a long while ago, but needs further discussion) I'd state secp384r1 and ffdhe6144 as "NOT RECOMMENDED" to bother with, but still permitted (or, alternatively, just not explicitly recommended and not recommended against).

I'd make the recommendation that X25519 and secp256r1, in that order, be sent in first-flight key shares, unless prior expectations exist for the server that another group is desired or required. Implementations would of course be permitted to send a more conservative set, such as (instead or additionally) X448 and ffdhe8192 or secp521r1, but even though I think this might make sense for 256-bit bulk ciphers, I concede that it would likely be overkill that wouldn't really help. Those who want something stronger should probably be refocusing their effort on getting some kind of PQ key exchange standardized.

Am I somewhere in the ballpark of what the WG might deem appropriate here? There has been a "TODO" note sitting in the draft to address this for quite some time, and I'd like to get something in here at some point. Just to restate: my goal here is a set of recommendations to narrow down the zoo, not hard requirements (beyond requiring ~128+ bit strength security).