Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Fri, 12 June 2015 16:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2CDC81A6EE8 for <>; Fri, 12 Jun 2015 09:13:06 -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 9LU0mOsVCmIP for <>; Fri, 12 Jun 2015 09:13:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7135D1A6F30 for <>; Fri, 12 Jun 2015 09:13:04 -0700 (PDT)
Received: by qcnj1 with SMTP id j1so11964647qcn.0 for <>; Fri, 12 Jun 2015 09:13:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=RSB5a3GO1OjNq4n5QqS49Mwv34GbNX5gLIhZjp4m43U=; b=G3tdFrf/vn/UvzHjf48xU/oKcne6CvUYuhCu2rJewyhGGFn1crBQHSyoSUwHJn+AYc H1MN0xidWUZ0m9au98Atu96bUY/tPVCYdtBXsiBQDJrBcU7vzudjmiwD0eB6/bzUOjJ3 p6vRqGYcINm8biYPmfxbBZvhJ5uIK2UZOP0rWZ4LIHW8yEsDk0zKcibY0qdVh5OdcLWr jDcKTIJbAu2TOAfjQSXIVraxycZZ/7KPJc6lm1hqJzaSenB88MS6cF3eES7Y/wYsYHO1 6hDtIGqdIXx4ekiuIlBxI/KbkcpwJXdYhNY6J5oFqZYtDG3bUfLbC9UuY15gBrFjRF1U a5gg==
X-Received: by with SMTP id i7mr32103131qkh.26.1434125583721; Fri, 12 Jun 2015 09:13:03 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id n132sm1838430qhb.12.2015. for <> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:13:03 -0700 (PDT)
From: Dave Garrett <>
To: "<>" <>
Date: Fri, 12 Jun 2015 12:13:02 -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="iso-8859-1"
Content-Transfer-Encoding: 7bit
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: Fri, 12 Jun 2015 16:13:06 -0000

On Thursday, June 11, 2015 03:58:21 pm Dave Garrett wrote:
> Here is a branch with a rough draft of an a la carte handshake algorithm negotiation scheme for TLS 1.3, based on discussions on this list.
> * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK.

The wording in my summary appears to have been not precise enough.

Quoting what's in the full draft, at the moment:
In TLS 1.3, the semantics of the handshake portion of cipher suites SHALL be interpreted as indicative of the newest standardized algorithm which is supported, rather than indicative of an exact combination which is offered. All implementations of this specification SHOULD only negotiate the usage of cipher suites with a handshake portion of "ECDHE_ECDSA" or "ECDHE_PSK". Implementations MUST NOT negotiate the usage of cipher suites with a "KEA" of "DHE", "DH", or "ECDH". Implementations MUST NOT negotiate the usage of cipher suites with a "SIGN" of "RSA" or "DSS", including cipher suites which do not have separate "KEA" and "SIGN" components.

"KEA", "SIGN", and "handshake portion" are defined in the same section as part of a generalized description of the de facto suite naming convention. This draft is based on PR #180, which doesn't change any spec/policy; just updates the section. A link to the current draft of this in full, rather than just the changes:

So, to be more clear (repeating what I clarified in replies to specific questions):

in cipher suites:
ECDHE_ECDSA or ECDHE_PSK  ->  SHOULD (not proposing a MUST, here)

this does not preclude the allowance of:
plain PSK
anything fundamentally new (e.g. post-quantum key exchange)
something else obscure, but not generally recommended

The goal here is to collapse the zoo of older suites under a small set of valid ones for TLS 1.3, and use the existing extensions to negotiate those capabilities instead. Actually dropping capabilities is not part of this, so even if doing so might be warranted, it would be part of another changeset and not this.

As separately replied to Viktor, yes, the anon issue needs updating in the draft. It might even be warranted to use only DH_anon suites instead of ECDH_anon due to its more widespread use. This would allow usage of ECC without having to specify any new ECDH_anon suites for those lacking them but already having DH_anon suites.