Re: [TLS] A la carte handshake negotiation

Nico Williams <nico@cryptonector.com> Tue, 16 June 2015 23:31 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 41C681B2A28 for <tls@ietfa.amsl.com>; Tue, 16 Jun 2015 16:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 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, 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 eMk-dR4LNJtu for <tls@ietfa.amsl.com>; Tue, 16 Jun 2015 16:31:14 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5D63B1B2A16 for <tls@ietf.org>; Tue, 16 Jun 2015 16:31:14 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 9F9EE163B; Tue, 16 Jun 2015 16:31:13 -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=JXSrLtu4Pe3nFv OZbpnNd+afTeM=; b=Gv3rvd4mcSbHLKl8MqHfxQkMgM4hyo9GlqkXOAIAfXMvIm 6QRaMZFfg0YYmUnkLc+wERdLXXqCAsR5rcPhC1xmfQIfSy0qzS8jCkdSWXzcYoCD j2/3t78ktzc2Pp3B3nnbr/NFS2ZyWMG0RT9txQ9r9w5QLhtQhu8Mx83yCbW+8=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 4D4201636; Tue, 16 Jun 2015 16:31:13 -0700 (PDT)
Date: Tue, 16 Jun 2015 18:31:12 -0500
From: Nico Williams <nico@cryptonector.com>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150616233111.GD6117@localhost>
References: <201506111558.21577.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201506111558.21577.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/O7L79Bm2moJMGDJQ6ZaZuT1I0g0>
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: <http://www.ietf.org/mail-archive/web/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: Tue, 16 Jun 2015 23:31:15 -0000

On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote:
> Here is a branch with a rough draft of an a la carte handshake
> algorithm negotiation scheme for TLS 1.3, based on discussions on this
> list.

Commenting on the latest update of that:

> https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte

 - Yes!  This.

 - IMO the hash should be associated with the "handshake portion" of a
   cipher suite, not the bulk side.

   Ideally it'd be:

      Hash_Algs x KE_groups x Server_auth_algs x Bulk_cipher_and_mode

   That's four registries instead of one or two.

   I'll settle for your proposal though!

 - It'd be nice if instead of always thinking of authentication as
   "signatures" we just thought of it as authentication.

   Consider authentication by using a DH cert...  If that's selected
   then the handshake won't be the usual one that we're all used to, but
   it would be workable.

 - 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, and the alternatives are wasteful (e.g.,
   doing signatures that aren't needed).

   Recommending against the use of anon ciphersuites is and should be a
   job for UTA.

Nico
--