Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <> Mon, 29 June 2015 06:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 27F4E1A1B66 for <>; Sun, 28 Jun 2015 23:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.198
X-Spam-Level: *
X-Spam-Status: No, score=1.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i6-5WvNlhr1u for <>; Sun, 28 Jun 2015 23:47:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A2911A1B5B for <>; Sun, 28 Jun 2015 23:47:28 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 9BE511A260A; Mon, 29 Jun 2015 09:47:26 +0300 (EEST)
Date: Mon, 29 Jun 2015 09:47:26 +0300
From: Ilari Liusvaara <>
To: Nico Williams <>
Message-ID: <20150629064726.GB12123@LK-Perkele-VII>
References: <> <20150626221456.GK6117@localhost> <> <> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII> <20150629055023.GP6117@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150629055023.GP6117@localhost>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
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: Mon, 29 Jun 2015 06:47:30 -0000

On Mon, Jun 29, 2015 at 12:50:24AM -0500, Nico Williams wrote:
> On Sun, Jun 28, 2015 at 10:44:03AM +0300, Ilari Liusvaara wrote:
> > "Chinese menus" with coupled choices are classical source of interop
> > problems.
> It's worked for SSHv2.

Also, the way SSHv2 key exchange and authentication is constructed,
the coupling in SSHv2 is much smaller than it seems. Also, errorneus
pairs can be easily recovered from.

> > Also, out of 6 points for kex/aux (after unifying DH, adding PSK and
> > renaming PKIX to CERT), only 4 seem sane:
> > 
> > 
> > KEY_TRANSPORT doesn't lead to anything sane without greatly different
> > key exchange.
> Key transport is its own authentication (like PSK).  It can be combined
> with key agreement, but it's much easier to combine key agreement with
> signatures instead.
> If we unify all the key agreement protocols, then I agree that we have
> few enough key exchange + server authentication mechanisms for now, but
> see below.
> > If new PAKE KEX would be added, it would add 2 combinations
> > fooPAKE+CERT and fooPAKE+ANON (6 for 7).
> We added GSS support to SSHv2, and I suppose we could add all sorts of
> server authentication options to TLS eventually.
> And if we don't unify some key agreement protocols, then we've still got
> a largish cartesian product.  Still, much smaller (and manageable) than
> with the bulk cipher suites thrown in.

I don't think it is that large...

And also, different kex/auth pairs change the handshake in pretty
fundamential ways.

GDH+GSS would presumably be very different from both GDH+CERT and
GSS+GSS or whatever.

Also, I think it is quite major undertaking to add a new kex/auth
pair (especially if it does something "odd" with respect to what's

> > The reason to have a plan for PRF replacement is that formally TLS 1.3
> > requires CR prf-hash (even if reality may be a lot less harsh). So if
> > SHA-2 ever breaks, there might be a lot of new ciphers....
> Why not use HMAC?

Transcripts use hashes. And if raw hash can be collided, HMAC can be
collided as well.

As said, one might need more powerful attacks against hash than
collision to actually break things, but security analysis breaks with
just CR failure.

> > (SHA-2 breaking would also cause problems with signatures, but that
> > is a separate matter and only partially solvable at TLS level).
> I agree that we should deal with each case separately and try to
> minimize future pain.

The "partially solvable" meant adding indicator of prf-hash into
CertficateVerify TBS.

The signatures themselves can't be helped.