Re: [TLS] A la carte handshake negotiation

Nico Williams <nico@cryptonector.com> Fri, 26 June 2015 22:15 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 48FE21ACE12 for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 15:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E5GDwjCvVd-E for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 15:14:59 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBC1ACE11 for <tls@ietf.org>; Fri, 26 Jun 2015 15:14:59 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 1E3E52005DD02; Fri, 26 Jun 2015 15:14:59 -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=PV/NxlztpWDz47 SYQjsi62MVYwE=; b=EENNml94GoG0pXixNSMHkAvk8cMpZb2peMPQ36/9nqLisn FceJgktonmNl6Ux81rX5FKrZ5629W2IHmnWyBGlOiKnmfhuio6PkvtDYD2JoK7gy uaxrddGOqmgNGc4eDack6L4RsfZzdIajkzRnl4K9jmVcSuMDQSMbgjVYQ2BxA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id 8AD022005DD00; Fri, 26 Jun 2015 15:14:58 -0700 (PDT)
Date: Fri, 26 Jun 2015 17:14:57 -0500
From: Nico Williams <nico@cryptonector.com>
To: David Benjamin <davidben@chromium.org>
Message-ID: <20150626221456.GK6117@localhost>
References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> <CAF8qwaCew287OLCdrgdKXbzbc+xWmT4eYWKfLJXLbTvEFVBJWA@mail.gmail.com> <20150626204731.GJ6117@localhost> <CAF8qwaAbgQMK7C4aJExUTz+kJBV=S5vuXy=Ba75NGqXqwABN9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAF8qwaAbgQMK7C4aJExUTz+kJBV=S5vuXy=Ba75NGqXqwABN9A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2OZzkZqWyORMXUfsu0Wb3yeg3ho>
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: Fri, 26 Jun 2015 22:15:00 -0000

On Fri, Jun 26, 2015 at 09:12:43PM +0000, David Benjamin wrote:
> On Fri, Jun 26, 2015 at 4:47 PM Nico Williams <nico@cryptonector.com>; wrote:
> > This can be fixed by having signalling cipher suite assignments for
> > negotiating a cartesian product of them (in addition to any actual
> > cipher suites offered).  [...]
> 
> Hrm. I might not understanding you right, isn't that roughly the same as
> defining new values:
> 
>   [...]
> 
> and saying that TLS 1.3 uses those rather than either ECDHE_RSA or
> ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite list
> for convenience and avoiding a new extension? That seems reasonable to me
> actually. If we avoid weird pre-1.3 interactions, I don't have opinions on
> new extension vs camping out in the old namespace.

Yes, they'd share the same cipher suite number (and name) namespace.

Pre-1.3 implementations would ignore these "new" cipher suites, which is
why still sending some old ones is important for interop.

Using an extension loses the ability to express old vs. new cipher suite
relative priorities.  That might not be a problem (with 1.3<->1.3 using
only the new thing), and if no one cares, then I wouldn't either.

> Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the
> common case can send a slightly shorter ClientHello? (For Chrome I think
> it'd be four bytes because we only do two AEADs.)

There's two different goals here:

1) "Compress" the ClientHello;
2) (maybe!) reduce the amount of bookkeeping to do in the cipher suite
   registry.

(2) is easier if we go with an extension instead of camping on the
cipher suite namespace.

We've failed to register useful cipher suites before.  We can probably
fix this anyways by writing tools for IANA to do the cartesian product
so that it's never again a manual process for RFC authors nor for IANA.

Elegance would also be a goal, except that it's too late for that.

Nico
--