Re: [TLS] A la carte handshake negotiation

Nico Williams <> Sun, 28 June 2015 05:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 12AC21A92F5 for <>; Sat, 27 Jun 2015 22:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.334
X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LT9JJ0du4EuL for <>; Sat, 27 Jun 2015 22:06:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 23C7E1A92F4 for <>; Sat, 27 Jun 2015 22:06:11 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 7B85120058F02; Sat, 27 Jun 2015 22:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=HHO4ot/mgUJySq 3wkRZMtGbCi8w=; b=aTkbuQlGbA2gpwa1ilCRNjMmQD8/1+sCKl3KlVh23/4iBG NsOh68L2BKOQ3f3oZdmqZjrY71rBia0TMzW2lpK6A12RQ/nKXyNo5PKmjOapsYz2 Xz12/vfbIVeYdthjwBGJY4q/yUipvQHelUTNcukQqDv4O6aar9dKEgQI6IPLQ=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 18FC72005E809; Sat, 27 Jun 2015 22:06:10 -0700 (PDT)
Date: Sun, 28 Jun 2015 00:06:09 -0500
From: Nico Williams <>
To: Ilari Liusvaara <>
Message-ID: <20150628050607.GN6117@localhost>
References: <> <20150626221456.GK6117@localhost> <> <> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150627080928.GA7886@LK-Perkele-VII>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Sun, 28 Jun 2015 05:06:12 -0000

On Sat, Jun 27, 2015 at 11:09:28AM +0300, Ilari Liusvaara wrote:
> > We could do even better: stop cartesian products altogether.
> > 
> >   TLS_SRV_AUTH_NONE (anon)
> >   TLS_SRV_AUTH_PKIX (certs)
> >   TLS_SRV_AUTH_PSK  (also authenticates the client)
> > 
> >   TLS_KEX_DH
> >   TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey)
> > 
> >   TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to
> >                               match the symmetric encryption suite's
> >                               strength)
> >   TLS_ENC_AES_256_GCM_SHA512
> >   ...
> > 
> > Key exchange, authentication, bulk+hash.
> One can't really decouple authentication and key exchange cleanly,
> especially because of PSK (KEX+Auth sets key exchange shape).

But I think it simplifies things if we separate them and note that some
mechanisms of one kind have a "twin" of the other kind.

Imagine that TLS 1.3 clients offer / servers select mechanisms for key
exchange and authentication separately but either may contribute to the
other.  Thus to do PSK without PFS the client would offer PSK for key
exchange, and PSK again for authentication.  If the client offers ECDH
for key exchange and PSK for both (and no others), then the server can
pick either PSK only, or PSK + ECDH; if the client offers ECDH for key
exchange and PSK for authentication (and no others) then the server must
do that (or fail).

Some combinations would be non-sensical, such as RSA key transport for
key exchange but PSK for authentication.  The server must not pick them,
but with the client only offering sets of mechanisms from which the
server picks, that's fine.  If there's no sane combination that could be
picked, then the client screwed up and the connection fails.

> Also, DH and ECDH (and perhaps some other things) do unify to GDH.

Yes.  Preferably all DH-like key agreement protocols should be unified,
especially when they can work with standard groups.

> Also, one way to do PRF-hash replacement would be to define sets of
> PRF-hashes, and have the symmetric algorithm pick algorithm from
> that set.

Sure.  I tend to think of the PRF as part of the handshake, so it's a
bit strange to associate it with the bulk cipher, but since we want to
match their strengths, it makes some sense.  We also have to match key
exchange and authentication strengths, but we want to succeed with a
mismatch provided we don't fall to realtime downgrade attacks -- the one
thing we can always match is the hashed and the bulk ciphers.