Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Fri, 12 June 2015 17:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D30F01ACD7D for <>; Fri, 12 Jun 2015 10:09: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 XLliVtfa4DoQ for <>; Fri, 12 Jun 2015 10:09:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC1EC1ACD7E for <>; Fri, 12 Jun 2015 10:09:28 -0700 (PDT)
Received: by qgg3 with SMTP id 3so13368243qgg.2 for <>; Fri, 12 Jun 2015 10:09:28 -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=+nfPEXLLnGjVTWEJIIQD43D7BURn9oAjyJ+T3PMuF5k=; b=lrZ0JjuebfhRjoZT/LXwyI7IklZfpjfpE7ryEiuYb3KaJUIL+USd/e9YsC6xmRCXa6 LVAxCNsc7Nc5W9RdJKLtta6OOr81PvN95BnYEKQda1StETbZpa5Fklxzm7OcTPG2GMco qIayEc5qj/sAfGALH1djxx43VWv1kfCjTrQOnXYqvCls6ge8jGsvvqX5y0BaKthqkf+i rr1Hr1zJaXSmg9Sp2VDa5OdVnbUV83TIJpTsVnlSPt78E8DVT4rmeSjR3a+8LE8owh4G o8GJL8P+OJzo0hyvCOOPioztZrFxy2DLp9UFBJGW7XwjnHETQOfJWiSNi0AxpgBhcPAW dwlQ==
X-Received: by with SMTP id c9mr33316763qkh.50.1434128968166; Fri, 12 Jun 2015 10:09:28 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id b31sm1927029qge.5.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:09:27 -0700 (PDT)
From: Dave Garrett <>
Date: Fri, 12 Jun 2015 13:09:26 -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 17:09:35 -0000

On Friday, June 12, 2015 12:55:59 pm Viktor Dukhovni wrote:
> I still don't understand preclude as a matter of principle negotiation
> of ECDH_anon with AEAD if DH_anon with the same bulk cipher would
> be allowed.  Once we have separate negotiation of the key exchange,
> surely ECDH_anon can be one of the supported key exchange variants,
> and then take advantage of all the available bulk ciphersuites.

EC/FF may be negotiated separately, but a suite still needs to be selected. Anon cannot be negotiated via an ECDHE_ECDSA suite, as the signatures extension explicitly prohibits proposing anon alongside actual signatures. One way or another, anon needs its own suites to be used.

> Or does this proposal simply compress the client HELLO message,
> but the server is still ultimately selecting the same all-in-one
> ciphersuite (thus requiring Nico's new code points for ECDH_anon
> with AEAD)?

The server still needs to select a suite. If it selects an ECDHE_ECDSA suite, then it can negotiate EC/FF and RSA,DSA,ECDSA with extensions. It cannot negotiate anon. To do so would require either an ECDH_anon or DH_anon suite be negotiated. Yes, the preferred route is to require Nico's ECDH_anon codepoints for AEAD ciphers. With an ECDH_anon suite, the groups extension can be used to negotiate EC/FF. What I was stating earlier is that we could theoretically do so with DH_anon if we wanted to, but I would much rather the ECDH_anon draft be resurrected and passed as it would avoid confusion and the appearance of contradiction.