Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Wed, 17 June 2015 00:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 779C91B307C for <>; Tue, 16 Jun 2015 17:31:53 -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 Gc60ivupwU85 for <>; Tue, 16 Jun 2015 17:31:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BED601B376B for <>; Tue, 16 Jun 2015 17:29:21 -0700 (PDT)
Received: by qkhu186 with SMTP id u186so18148758qkh.0 for <>; Tue, 16 Jun 2015 17:29:20 -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=76qL534WBE3NfctA+KGi3D5yW1qZMXUupIKT9m0Gqag=; b=o8ky0uzS6anznUb1zbeLgdB/bMRka/vRCHkV8dgszrWY+g7wMtj3DI40+38CiEx3aI Q1z0XE6E4J3oVGS77YgdBnXw9iuto3aFkxVytrMYiwuC0WqTH4RQfIqK7AFO4r7IKwoP /v3t0S+kTW3jPE7zQYT72rZLunCrKypodwEu3vfC412aHc+ljnBZ4EbVug2HD7FeOxn+ 9u2iq/sBYucs+EHtEPGeDngSS8gbCyUzWBjgM/PsLxqnv54kxDbiECJjSTi1HncmIGet 21xBaPyOV6PdO6fFr+rcMtgCxuxiYUp8bMRu6FI19iNcP3fiG3pKMr5pSM+ryl6hqxup xD+g==
X-Received: by with SMTP id z123mr7286048qkz.92.1434500960731; Tue, 16 Jun 2015 17:29:20 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id e49sm1338748qga.49.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jun 2015 17:29:20 -0700 (PDT)
From: Dave Garrett <>
To: Nico Williams <>
Date: Tue, 16 Jun 2015 20:29:17 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <20150616233111.GD6117@localhost>
In-Reply-To: <20150616233111.GD6117@localhost>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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: Wed, 17 Jun 2015 00:31:53 -0000

On Tuesday, June 16, 2015 07:31:12 pm Nico Williams wrote:
> >
>  - Yes!  This.
>  - IMO the hash should be associated with the "handshake portion" of a
>    cipher suite, not the bulk side.

The bulk cipher and hash are often directly correlated. (e.g. SHA384 paired with AES-256) The signature algorithms extension lists hashes for each certificate type.

>  - Anon ciphersuites...
>    I'd much rather that the WG did NOT deprecate these!
>    For opportunistic security and channel binding applications anon
>    ciphersuites are just fine

The alternatives in the current draft proposal are raw keys with trust after anon connect and fully anon via PSK. The reason for wanting to deprecate these suites is that this feature is under-maintained in the spec. There are currently no ECDHE AEAD anon suites. We'll want to publish an RFC to define new codepoints for ECDHE PSK suites to match existing DHE versions, but having to double that for anon is a bit of a mess (and some are against it). Folding anon into PSK as a special case simplifies things and makes cipher support not as much a side issue / afterthought.

Logically, anon is a globally pre-shared null key, so it makes sense.

> the alternatives are wasteful (e.g., doing signatures that aren't needed).

The currently proposed anon PSK has no overhead. Anon PSK is just id="anonymous" and a NULL key. (EC)DHE is used as normal. The only difference in computation is that the pre-master secret with anon PSK is DHresult + 0x00010 (where `+` is concat). Tacking 5 bytes onto the end of the DH result, once a handshake, is essentially zero overhead.