Re: [TLS] A la carte handshake negotiation

Dave Garrett <davemgarrett@gmail.com> Mon, 15 June 2015 15:40 UTC

Return-Path: <davemgarrett@gmail.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 2916E1B2EE4 for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 08:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 gr0i72d0ZK5b for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 08:40:26 -0700 (PDT)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5FF1B2EF5 for <tls@ietf.org>; Mon, 15 Jun 2015 08:40:25 -0700 (PDT)
Received: by qcwx2 with SMTP id x2so3927005qcw.1 for <tls@ietf.org>; Mon, 15 Jun 2015 08:40:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=nB1rGHB6TbzRZ0DgjtFKvUsq9uo3ZJl+2sQ5MpUWlHc=; b=WU7cExH78e95DpWWPgBjSP/Vwu5W0PPbvIyjgIjt54Nm+QvOwoEFK+rSnIzwkWuRYN WMB5NMS6VpO1RWEL8p6t07p2w3kDE+9WLnaFP4FbF+wqshuqzicwUL4JgicxPtL6jXYj IDnaLLZy+08UYGz1dtXAhqFwZsQhBvdUSjthLO/FGM7AYDc3MU4RxUk5xYDZ1T9KdpyR K3CgXmhC+GcjLO9FX3oEeDocjAzuWg5eNv3H36LhGWJ1oQ8q5brDb8bl9C+mjUBRyP8B ++vADvta+nusMAYB+r2F7pm9Yn3qytzC3OcSSj5PKr8H29ZOzhHG07LjRT6MGqJk92DL pumg==
X-Received: by 10.140.133.9 with SMTP id 9mr37927614qhf.5.1434382825184; Mon, 15 Jun 2015 08:40:25 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id g92sm6474333qgf.20.2015.06.15.08.40.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 15 Jun 2015 08:40:24 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 15 Jun 2015 11:40:23 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201506122145.13790.davemgarrett@gmail.com> <20150615135023.GA28680@LK-Perkele-VII> <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com>
In-Reply-To: <4377771.p3nGbdM9qk@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201506151140.23411.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/OwxOsVWzc0Gn5DT8L3l7R1ktFQQ>
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: Mon, 15 Jun 2015 15:40:28 -0000

On Monday, June 15, 2015 10:30:16 am Hubert Kario wrote:
> On Monday 15 June 2015 16:50:23 Ilari Liusvaara wrote:
> > On Mon, Jun 15, 2015 at 03:36:44PM +0200, Hubert Kario wrote:
> > > On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote:
> > > > On Mon, Jun 15, 2015 at 12:10:39PM +0200, Hubert Kario wrote:
> > > > > Especially with the case of overloading the ECDHE to handle the
> > > > > ECDH_anon,
> > > > > it makes it possible that many implementations will reintroduce state
> > > > > machine bugs...
> > > > However, if we were serious about eliminating state machine bugs (and
> > > > TLS
> > > > 1.3 state machine is totally different from TLS 1.2), we would eliminate
> > > > all optional messages (different from context-sensitive messages, like
> > > > Server key exchange message), and then eliminate handshake message types
> > > > (except for those which have to have type numbers for backward
> > > > compatiblity).
> > > 
> > > there's a difference between having messages which are optional from
> > > protocol standpoint but are mandatory for given ciphersuite and messages
> > > which are optional always
> > 
> > Well, the former are what I called "context-sensitive". And presence or
> > absence of those can be inferred from the past handshake.
> 
> yes, and I'm saying we should be careful not to introduce ones which can not 
> be inferred from previous messages
> 
> putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes this 
> likely

I do agree that there is a risk of implementations introducing bugs. It's a matter of which new system with the potential for bugs we think has a lesser risk in comparison to the combinatorial exploded mess we have now.

The compromise between the current line of discussion (ECDHE_ECDSA for everything) vs. what is currently in my proposal on GitHub (ECDHE_ECDSA | ECDHE_PSK | ECDH_anon) could be to only merge all the certificate authentication under ECDHE_ECDSA and merge PSK and anon under ECDHE_PSK. This would have certificate based suites and non-certificate based suites as fundamentally separate, but still notably reduce the number of suites that have to be worried about in the specs. (anon just becomes a special case of PSK)


Dave