Re: [TLS] A la carte handshake negotiation

Nico Williams <nico@cryptonector.com> Fri, 26 June 2015 20:47 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 9B4C61ACD66 for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 13:47:36 -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 aIEKHO7kDi5J for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 13:47:35 -0700 (PDT)
Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B61781ACD83 for <tls@ietf.org>; Fri, 26 Jun 2015 13:47:35 -0700 (PDT)
Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 7228920058D39; Fri, 26 Jun 2015 13:47:35 -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:content-transfer-encoding; s= cryptonector.com; bh=q0iyingMsS60rZ5YGXONkKxtmZg=; b=pQU6skktQIN yoT8bWQWp6QHVadXgTlqntxIulFg4MpfX5W4QgMfh5WEs4wtpVaQqq+/ZxBfnUxy UPEv6WgVRRaplroKHmwy1G95/M4AbpxPTyE/sNpBLKenoyrHdOEmDWW2hsPUO4ZG L+Hk5icviOHtIvfikT1RvVq3bWo/wp7s=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 30FAA20058D36; Fri, 26 Jun 2015 13:47:33 -0700 (PDT)
Date: Fri, 26 Jun 2015 15:47:32 -0500
From: Nico Williams <nico@cryptonector.com>
To: David Benjamin <davidben@google.com>
Message-ID: <20150626204731.GJ6117@localhost>
References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> <CAF8qwaCew287OLCdrgdKXbzbc+xWmT4eYWKfLJXLbTvEFVBJWA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAF8qwaCew287OLCdrgdKXbzbc+xWmT4eYWKfLJXLbTvEFVBJWA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/bwtsHQG-6VUOq6sXnBC4c_LZySA>
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 20:47:36 -0000

On Fri, Jun 26, 2015 at 07:02:32PM +0000, David Benjamin wrote:
> On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett <davemgarrett@gmail.com> wrote:
> >
> 
> I have the same concerns with this version as before. I don’t believe it
> lowers the risk of accidental interop failure---if anything, it makes it
> worse.
> 
> This scheme is still a problem for Chrome on Windows XP. This proposal
> effectively makes ECDSA (and ECDHE) MTI for any clients doing the standard
> PKI-based handshake. Whether or not this is desirable, it certainly should
> be spelled out clearly in the spec.
> 
> Imagine how implementations look. Most allow configuring the cipher suite
> list. This now interacts subtly with configuring 1.3 ciphers, and we have
> the same interop risks of a parallel extension. What if the consumer, for
> whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but included
> ECDHE_RSA? Now 1.2 servers work, 1.3 ones don’t. Alright, so what if we
> internally checked for consistency? That’s fine, but we could just as
> easily have checked for consistency between 1.2 cipher suites and a new 1.3
> mechanism.

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).  This allows for a) compression of negotiation,
b) fallback support for 1.2, 1.1, and 1.0, and c) expression of
preference for specific cipher suites ahead of (or after) the cartesian
product cipher suites.

We'd still end up with a cartesian product in the registry, but missing
registrations implied by the negotiation signalling cipher suites could
still work.

> If the worry is state-machine bugs due to PKI and PSK key exchanges being
> different, we won’t guard against them by separating
> ECDHE_PSK_WITH_AES_128_GCM_SHA256 from ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
> No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a codepath from
> ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar cipher suites
> will be funneled together anyway.

+1