Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Sun, 19 July 2015 20:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4308E1A8999 for <>; Sun, 19 Jul 2015 13:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6gdTtpUsC54A for <>; Sun, 19 Jul 2015 13:22:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 840E91A88D3 for <>; Sun, 19 Jul 2015 13:22:50 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so101757674qkd.3 for <>; Sun, 19 Jul 2015 13:22:49 -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-type:content-transfer-encoding:message-id; bh=vggP0VRkoMrY+hRn2SlFD9tW0d1gG3OOVtc44m20Xp4=; b=tKXRtvg12F6enZ8pS/TQPzgEGOOFUs5Op9kf1Dnr7HcciP9gVKYr6RcEkKFKOzx3Ob 7gVN9ud87xycu+9LTK2xYRkXIPcKEXqyHLadvSi4pA2oS9q0y1zTAJmtFP+fs/JYnAKp kyGam4PkyaDFwoJZwkD8CS67kVlIqGt5JUc6ZNrns6UeYfo02kf/ArpNC/09PYGHBAuA pbCeuTTlTQcJV4cBsz2Ah/FLGnM/b39EkN3Rr34ywUviQVQVIBdLZolmyDYE+hEIGCYt ZxGy5cg/CIRuMqJYE7EW8zGw/i0zYNWIiHaHr5EMsmnD+fhX6FGoPOYXdrwATB0W9NKr X7tQ==
X-Received: by with SMTP id y60mr41429544qgd.90.1437337369805; Sun, 19 Jul 2015 13:22:49 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id p185sm9152124qha.2.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jul 2015 13:22:49 -0700 (PDT)
From: Dave Garrett <>
To: "<>" <>
Date: Sun, 19 Jul 2015 16:22:47 -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: 7bit
Message-Id: <>
Archived-At: <>
Cc: Manuel Pegourie-Gonnard <>
Subject: Re: [TLS] A la carte handshake negotiation
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: Sun, 19 Jul 2015 20:22:52 -0000

Since the last time I posted it here, I've made some changes. Everything is rebased on top of what is now PR #201 (it's not really severable from that).

Now that resumption is PSK-based, some of the language might need tweaking for that, but I not everything is sorted out for PSK-based resumption yet. (there's TODOs in the draft; e.g., doesn't yet say what cipher suites are to be used for resumption)

Other than that, it's at a state that (with PR #201) I could submit a PR if we can agree that this is the general path forward. The highlights of this proposal, for those who didn't follow the previous (long) discussions on the topic:

* All DH, DHE, ECDH, RSA, and DSS cipher suites are deprecated. (some could still be offered for backwards compatibility, just like before)
* The only compatible cipher suites would be those with a handshake portion of ECDHE_ECDSA, ECDHE_PSK, PSK, or ECDHE_anon. (there is an exception in there for completely new stuff, which will essentially be amending this anyway)
* All ECDHE_ECDSA suites can negotiate ECHDE/DHE & ECDSA/DSA/RSA via the existing extensions. (no new extensions need to be defined to do this)
* Likewise, ECDHE_PSK and ECDHE_anon can negotiate ECHDE/DHE via the existing extension.
* A new standards track RFC to promote ECDHE suites from informational is needed, but that was already true.
* In addition to reducing combinatorial nonsense with the suites, it results in deprecation of existing DHE suites in favor or DHE done via ECDHE labeled suites only with strong groups.

This is the general result of previous discussions. The alternate route that came up was just to ditch the concept of cipher suites entirely and add a new extension to negotiate the AEAD cipher/hash to use with the existing extensions. There's nothing that would preclude moving to that more extreme route if this were to be accepted first, as ECDHE/DHE negotiation via the extension would be needed for that too. I think the WG is more in favor of the route proposed in this changeset at the moment, though.