Re: [TLS] A la carte handshake negotiation

Viktor Dukhovni <> Fri, 12 June 2015 17:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF2571ACD9D for <>; Fri, 12 Jun 2015 10:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pzjcxT27oAAN for <>; Fri, 12 Jun 2015 10:22:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFA211ACD45 for <>; Fri, 12 Jun 2015 10:22:00 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 38EBA28494C; Fri, 12 Jun 2015 17:22:00 +0000 (UTC)
Date: Fri, 12 Jun 2015 17:22:00 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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:22:02 -0000

On Fri, Jun 12, 2015 at 01:09:26PM -0400, Dave Garrett wrote:

> 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.

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.

> > 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.

So be it I guess.  I wish it were simpler...