Re: [TLS] A la carte handshake negotiation

Nico Williams <nico@cryptonector.com> Mon, 29 June 2015 05:50 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94A1A0263 for <tls@ietfa.amsl.com>; Sun, 28 Jun 2015 22:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.234
X-Spam-Level: **
X-Spam-Status: No, score=2.234 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mLFq9uwUGtL for <tls@ietfa.amsl.com>; Sun, 28 Jun 2015 22:50:26 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA551A0222 for <tls@ietf.org>; Sun, 28 Jun 2015 22:50:26 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id BA7E710060; Sun, 28 Jun 2015 22:50:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=isYDew2l4Jj1Ci jlxITBM0zoig4=; b=ORXq93u+CtdRbavLGJWEDUzeIWUvkGffsdwvL0ncFZlDLa ifojlDM0KnGng9wqDmNt4FRP13hqCCNaowU0NRB6rXNApP9cNjxeTpel/ZNrRzZA onwPZ8ynxLW6cKrDM6JSqgqtdk5XsNxdK+Czm3sbzHdBo2mnpyVfT+TdOq+V4=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 5700C1005D; Sun, 28 Jun 2015 22:50:25 -0700 (PDT)
Date: Mon, 29 Jun 2015 00:50:24 -0500
From: Nico Williams <nico@cryptonector.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Message-ID: <20150629055023.GP6117@localhost>
References: <201506111558.21577.davemgarrett@gmail.com> <20150626221456.GK6117@localhost> <CAF8qwaAkBAXDkhd3zU=uO1t-dv7iu0bhb9bH28JHROrWp98SEA@mail.gmail.com> <201506261924.24454.davemgarrett@gmail.com> <20150627014034.GL6117@localhost> <20150627080928.GA7886@LK-Perkele-VII> <20150628050607.GN6117@localhost> <20150628074403.GA13633@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150628074403.GA13633@LK-Perkele-VII>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/RJSze_xXx1rP5BDCpkggN0roEhQ>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] A la carte handshake negotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2015 05:50:27 -0000

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, out of 6 points for kex/aux (after unifying DH, adding PSK and
> renaming PKIX to CERT), only 4 seem sane:
> 
> GDH+CERT
> GDH+PSK
> GDH+ANON
> PSK+PSK
> 
> 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.

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

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

Nico
--