Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Sat, 13 June 2015 19:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9209F1ACE5C for <>; Sat, 13 Jun 2015 12:47:34 -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 yL1wU2nRc4hJ for <>; Sat, 13 Jun 2015 12:47:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED4A21ACE5B for <>; Sat, 13 Jun 2015 12:47:32 -0700 (PDT)
Received: by qcnj1 with SMTP id j1so17956032qcn.0 for <>; Sat, 13 Jun 2015 12:47:32 -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=TSDmlb4MOdfPTYLsfZcN6ltF/COKvgKwr+omcSVkc+A=; b=o72c40HynwsVm+wUGewP0u6bInExJxWnfx4ZQrVGVxu22zDCBQxQq6Ljm9yIBvMhbT 6ZfqwRmQeyLHMeJ+sUDGCOlV+4Bfog4OZeeRVw2wC5dcogzhFyni2gN18czGL+PRwLny GwbxpW5iweeN/s1RH2+fOcgPbui6BbHFNcHXAipRUzwiB5Wckn6Nr6kYHTvJzFO7qhOk Gk2q3dC4MOjE5u6n4caDeN5rM5Ys6SaYc/ZlVVkC+4nhfhI6Iy4ttXvrtuXDIgg9X8Mf zIKL0X3bc9RamK05P7h63Fw+4ADiTPAT+oeHE2QCE8S6YCnMK+BVjpkhSkZylI3bAFCq Lp7A==
X-Received: by with SMTP id c198mr20957852qka.48.1434224852294; Sat, 13 Jun 2015 12:47:32 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 97sm1153648qgl.4.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 12:47:31 -0700 (PDT)
From: Dave Garrett <>
To: David Benjamin <>
Date: Sat, 13 Jun 2015 15:47:29 -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: "<>" <>
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: Sat, 13 Jun 2015 19:47:34 -0000

On Saturday, June 13, 2015 03:19:20 pm David Benjamin wrote:
> On Sat, Jun 13, 2015 at 2:59 PM Dave Garrett <> wrote:
> > Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required
> > under this proposal.
> Perhaps I'm misunderstanding your goals here then. My read of (4) above was
> that this was intended to use the ECDHE_ECDSA representative of, say,
> AES_128_GCM as the spelling of AES_128_GCM (so effectively repurposing the
> cipher list as the list of AEADs[*]), and that this wouldn't actually
> translate to offering ECDHE_ECDSA due to that really being negotiated by
> the other two extensions.
> But this doesn't seem to be completely the case because the ClientHello is
> interpreted by both TLS 1.3 servers and existing servers. And so we need to
> consider the effects on both to avoid interop. issues.

This proposal could be extended to allow any cipher to negotiate any handshake based on the extensions, but that leaves us with a din of cipher suites. TLS 1.3 implementations would have to allow:

negotiate DHE/ECDHE + RSA/DSS/ECDSA from all suites with any of the following:
DHE_RSA, DHE_DSS, DHE_ECDSA, ECDHE_RSA, ECDHE_DSS, ECDHE_ECDSA (some of these combos don't exist, though)

negotiate DHE/ECDHE + PSK from all suites with any of the following:

negotiate DHE/ECDHE +anon from all suites with any of the following:
DH_anon, ECDH_anon (or named as: DHE_anon, ECDHE_anon)

We could do this, but it's more to keep track of.

By restricting TLS 1.3 suites to just those prefixed with ECDHE_ECDSA/PSK/anon, this means all others can be completely ignored for TLS 1.3+ and DHE suites can be deprecated in general.

DHE weak param negotiation is a problem, but negotiation via the extension uses strong groups. Requiring ECDHE prefixed suites also prevents negotiation of DHE with weak params with older implementations, as it's not even offered.

> [*] As you say below, not quite because you still premultiply the really
> exotic things like PSK and anon. But setting those aside for the sake of
> discussion.

I set them aside for the sake of discussion for the first draft of this proposal and most of the discussion ended up on being how to deal with them. They complicate things, but they need to be taken into account from the start regardless of which path we pick.