Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Sun, 14 June 2015 00:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 17E671A8988 for <>; Sat, 13 Jun 2015 17:44: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 Y76t-dNgIq9j for <>; Sat, 13 Jun 2015 17:44:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95E371A897D for <>; Sat, 13 Jun 2015 17:44:50 -0700 (PDT)
Received: by qkhq76 with SMTP id q76so35673706qkh.2 for <>; Sat, 13 Jun 2015 17:44:50 -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=yd3JSkSyH1t1grLhS0nVSRntM3VrjwSY/+JlICnxWJ8=; b=zHQ3LypjBlJqYl1DmH8BajrHoUVx60aXVOyvAwN3jt/Be3Ix+wvF60tssIbeAIcTVw UVBiDPcZ9j46RfMcIZWRmFOKeYSfOG5MhLgg2PDjM7PaHnoM9mSiHqzcMawj6v5X5JBz hNJdPk5kkJFglLxv1JHlf2B1UfUkN2SPPq3kFuVFpf1W8sC8dA4IotWNp9QQlo06Ec2H ODgT4voPJs1zcUv49+p+OdVK5QefpngmHzgk6EFtc4pd59qwHno6QHAECQEYS8apeN1Z D5W0eqMxmuBUfVYarK6PRxQRPOZuSvJJzy6PtEmX6QBXHLzSOsUTWm9/su28c1zryKWG b8Sw==
X-Received: by with SMTP id b12mr44317055qka.22.1434242689952; Sat, 13 Jun 2015 17:44:49 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id b191sm3983068qka.14.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 17:44:49 -0700 (PDT)
From: Dave Garrett <>
To: "<>" <>
Date: Sat, 13 Jun 2015 20:44: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: quoted-printable
Message-Id: <>
Archived-At: <>
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, 14 Jun 2015 00:44:52 -0000

On Saturday, June 13, 2015 06:29:31 pm Eric Rescorla wrote:
> On Sat, Jun 13, 2015 at 6:20 PM, Dave Garrett <> wrote:
> > On Saturday, June 13, 2015 04:43:18 pm Salz, Rich wrote:
> > > > It wouldn't be quite as simple as you propose, though, because we'd
> > > > definitely have to add a new way to declare anon or PSK support via
> > > > extensions, but that's doable.
> > >
> > > Or we don't support those features in 1.3.  Something we should think about?
> >
> > Completely dropping support for PSK & anon is not likely to get consensus.
> Certainly not PSK.

Anon could be replaced relatively easily, though: it's essentially just null PSK.

Define the null PSK identity to use a null key, and then all (EC)DHE_PSK suites can be used similarly to (EC)DH_anon. You just need to have the client propose the PSK identity in the ClientHello via an extension, which is already on the table in ekr's current WIP branch.

PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in “signature_algorithms” extension. (this was suggested by someone at some point on this list, but I don't remember where that discussion was, offhand)

With the above, ECDHE_ECDSA becomes the one-true-prefix. TLS 1.3 would only negotiate cipher suites of that prefix, and cipher suites would be solely for negotiating the symmetric cipher. All (EC)DH(E)_PSK & (EC)DH_anon suites would be deprecated, in addition to the older suites currently proposed to be deprecated (DHE, DH, ECDH, RSA, DSS).

This would simplify the current proposal without the need to create a new AEAD cipher negotiation extension as suggested by David Benjamin.

The only caveat is plain PSK, which has three options:
1) Define NamedGroup=null(0) for it to be negotiated via the “named_groups” extension.
2) Drop it and only use (EC)DHE_PSK.
3) Keep TLS_PSK_WITH_* suites around just for this.

Frankly, anything so constrained that it can't use an ECDHE exchange with PSK probably has no incentive to upgrade to TLS 1.3, or possibly even to an AEAD cipher. I would prefer simply mandating (EC)DHE usage with PSK and anything that can't even use the fastest ECDHE curve can stick with TLS 1.0-1.2 forever.