Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Sun, 14 June 2015 01:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 758C31A8850 for <>; Sat, 13 Jun 2015 18:15:41 -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 9qRN5rdQb4QF for <>; Sat, 13 Jun 2015 18:15:39 -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 9908E1A87E9 for <>; Sat, 13 Jun 2015 18:15:39 -0700 (PDT)
Received: by qcxj20 with SMTP id j20so2962162qcx.2 for <>; Sat, 13 Jun 2015 18:15:39 -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=NusVBPvnXz3fBja8KQp5TvACMyhs764joSS4oZVWzvs=; b=cARIYkK+Ac8UxCIJfBcGHdCpH3eqS25zDyvlnTV3Nsw0AXnWXSJgZULWfON43JZl0a jT5QbZu7OkzTTwJsxpjbyiPpeKfgZSZ2PvDQ0iSIrdtctKbVMDOyyEmmXDK/6bbCxYBC cm0ILNZa7QPCfHva6kQlqhKqJ0fsPJ4vEos+CYV3p2EY/Org0uvrY3FqOewHuaWE99QM GnqXBCffFjbWDDUalxB6Wqv/w7wz/rPVbw3VKLXYbf1+YaqyFURjKqC/OfhUR7/bmyXc rkH7GXEfbN7fT+gYn7z45bBAYQTJ0eMjwi2pdBCubIsQW0nlqEpW23bOiKH98lAadbMA cxHg==
X-Received: by with SMTP id f30mr46079086qki.104.1434244538975; Sat, 13 Jun 2015 18:15:38 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id z3sm4045452qge.30.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 18:15:38 -0700 (PDT)
From: Dave Garrett <>
To: Eric Rescorla <>
Date: Sat, 13 Jun 2015 21:15:35 -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 01:15:41 -0000

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.

Anon would be proposed the same way, just with a null PSK identity. All security comes from the FS from (EC)DHE. (just like (EC)DH_anon)

The server could simply state acceptance of negotiation by echoing back the same PSK extension.

> > With the above, ECDHE_ECDSA becomes the one-true-prefix.
> Maybe I'm misunderstanding what you're saying here, but I don't understand
> this point. Certainly I don't see any significant support whatsoever for
> deprecating RSA signatures, and given that we just standardized FFDHE, I don't see much
> evidence of consensus for deprecating DHE either.

This is all in the context of the proposal discussed in this thread. RSA signatures would be negotiated using the "signatures_algorithms" extension. DHE would be negotiated via the "named_groups" extension. (pick an FFDH group for FFDHE or an ECDH curve for ECDHE) The point is to negotiate any of the following via those two extensions and the ECDHE_ECDSA prefix:

This would give us fewer suites with no new extensions beyond those already proposed. Just need to use the already proposed extension additions and add a codepoint for PSK/anon.