Re: [TLS] A la carte handshake negotiation

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4CEF91ACE22 for <>; Fri, 12 Jun 2015 10:49:13 -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 fZAjYMpzsiq7 for <>; Fri, 12 Jun 2015 10:49:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF9681ACE21 for <>; Fri, 12 Jun 2015 10:49:11 -0700 (PDT)
Received: by qkhp85 with SMTP id p85so13036477qkh.1 for <>; Fri, 12 Jun 2015 10:49:11 -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=xbox0x3r/l6l6Tfn8EDlFYXXibjbooiFSRmtFpDBWfM=; b=UBeeAkBO1FjMhIAli3qGNeQEsW8Ear83zA21MQIl17H9avg864L7eW1LR76goMtbdx KKFZb2Ji5BXgJPAXT0a6dlqVMUaGzWP3wkdWZ2ePBHPWDR2U3L6Qn1WTLFCL4M1BQwX6 Gl39sX3WcrHuxLNhYoZPWLPT0VWbqKgbahRsg5b/0TlbJZjp2dmz+jD8FqPSCAyIYmWU n8lCSvW1IgsagVJL0ECyPQ/hGxsNA3A+Q/RpJC7GqlHOVzPCJWKQQONtPZxszD9I9YbS zb/6Dc1hH2n4BleFk8WIWWrx/zOie6LKqlH+c41Xm7KW7CCVsZHvHp71xyPh/Ubh0g7w R1Kg==
X-Received: by with SMTP id l37mr32358798qkh.88.1434131351292; Fri, 12 Jun 2015 10:49:11 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 41sm1971330qgf.47.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:49:10 -0700 (PDT)
From: Dave Garrett <>
Date: Fri, 12 Jun 2015 13:49:09 -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:49:13 -0000

On Friday, June 12, 2015 01:22:00 pm Viktor Dukhovni wrote:
> The extension definition can presumably be updated in a way that
> allows peers that support additional code-points to treat one of
> those as being "anon".  Is the current definition really a serious
> obstacle to solving the problem in a properly orthogonal way[?]

Technically, the extension could be hacked to work like that by adding an `anonymous_real(4)` in addition to the existing `anonymous(0)`, but that feels like the wrong way to go about this. I generally agree that anon and authenticated should be kept separate, so I don't want to do that.

The whole point of this negotiation proposal is to use _existing_ extensions to do this negotiation, rather than overhaul everything. The groups extension is already being modified to add FFDH groups alongside ECDH curves, but modifying the signatures extension to do anon would be more than just an addition; it'd overrule the previous behavior.

The best route for integrating anon into this scheme for TLS 1.3+ really does seem to be to publish new ECDH_anon suites for ciphers that lack them and require those be used with EC/FF being negotiated via the extension. TLS 1.2 would benefit from adding them, anyway.