Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Sun, 14 June 2015 03:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 887711A8944 for <>; Sat, 13 Jun 2015 20:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e1UO3hqFzz6v for <>; Sat, 13 Jun 2015 20:36:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F24F71A8942 for <>; Sat, 13 Jun 2015 20:36:10 -0700 (PDT)
Received: by qgf75 with SMTP id 75so19434590qgf.1 for <>; Sat, 13 Jun 2015 20:36:10 -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=BbxGgLIJYY3lXvr+bFnYMpcvau5V4Dlbdlt1IEqPY4s=; b=lEC8uLzLxpZ64e4POBgsh7VfQn6YtuXwZe594y0l0sMnUZWcv46a+5czMIIYL9rSOK GD36ovNkXAHdhf93+oGefMikdE0DTDrCcPQxGToD6rQ717nKxFVFk6Ii+gf7Y43EQCwM Z6BqAR2zL1oQDpQIGFS8Ir3GmFRbRVmQYWY1tuUYFqJUGqkgE/nOcEPJ3c9d2ARjWz6t ZnZJR9pqF21laafRHAvmvh4+sEN8Lhl4uenBYod03GMOg1guO5+Uaq3ugXuj6oknFxXL aTfvvJVtJjj/GyKBletQfXs7Ryssl1fa5EaucB5xxvi1eaVdSCWsAkOnFU0p7FqWjJqD ch7A==
X-Received: by with SMTP id z109mr27882245qgd.39.1434252970297; Sat, 13 Jun 2015 20:36:10 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 33sm4177815qkq.41.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 20:36:09 -0700 (PDT)
From: Dave Garrett <>
To: Eric Rescorla <>
Date: Sat, 13 Jun 2015 23:36:08 -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: <>
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: Sun, 14 Jun 2015 03:36:12 -0000

On Saturday, June 13, 2015 10:04:46 pm Eric Rescorla wrote:
> On Sat, Jun 13, 2015 at 9:15 PM, Dave Garrett <> wrote:
> > On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote:
> > > On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett <> wrote:
> > > > 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
> > >
> > > I don't see how this is going to work. All of the PSK cipher suites use the
> > > PSK as a source of keying material
> >
> > A client proposing the PSK SignatureAlgorithm codepoint and a PSK identity
> > would be offering to negotiate PSK using that key.
> But again, PSKs in TLS use it as a source of keying material, not just
> authentication. So, using that as a SignatureAlgorithm seems... weird.

It already has a non-cert value in there for anonymous (that can't be used, which is also weird), but I agree with your point.

We could instead have no PSK sig point and just have the PSK identity extension be the only thing to negotiate PSK. We don't really need both. In fact, PSK-only clients wouldn't need to bother with the signatures extension at all. Plain PSK would be as simple as just not offering the groups extension, either.

NamedGroup select FF group or EC curve -> FFDHE / ECDHE
SignatureAndHashAlgorithm list -> RSA / DSA / ECDSA / EdDSA
PSK_identity -> select key by id / null for anon

All cipher suites used would be ECDHE_ECDSA, but these extensions would be able to negotiate from any of the above. Cipher suite negotiation would be only for selecting the symmetric cipher (+hash to go with it). The extensions would do the rest.

To reiterate the rationale for considering this:
* DHE suites need retiring because of weak param negotiation and old Java choking on mitigations.
* Endpoints won't be able to fail a handshake anymore just because the admin missed one of the possible combinations of cipher suite components, even though they should be compatible. Also, more subtly, they won't accidentally negotiate a suite that's only in there for backwards compatibility as easily. (e.g. I've seen instances where one client gets an old cipher because its new cipher combo is low in the list, as the server admin probably only tested with another client that picks a slightly different combo higher in the list.)
* Simpler config overall; now a list of yes/no that can be individually prioritized, instead of having to prioritize all arbitrary combos.
* Less ClientHello size bloat from adding lots of suites. Large hellos can cause interop failure due to bugs.
* Easier to amend. There was discussion of hand-waving EdDSA~ECDSA. With this, it can have its own signature algorithm point and nothing else special is really needed (beyond using the frozen suite prefix, like everything else does). A future completely different algorithm could be added without having to muck around with cipher suite combinations anymore. (e.g. post-quantum algorithms will be needed, eventually; once defined with a sig point in the extension, all symmetric ciphers could use them right away)
* Anon or PSK can be used with any symmetric cipher without having to standardize suite values anymore.