Re: [TLS] A la carte handshake negotiation

Dave Garrett <davemgarrett@gmail.com> Fri, 12 June 2015 17:09 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 D30F01ACD7D for <tls@ietfa.amsl.com>; Fri, 12 Jun 2015 10:09:34 -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 XLliVtfa4DoQ for <tls@ietfa.amsl.com>; Fri, 12 Jun 2015 10:09:32 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 CC1EC1ACD7E for <tls@ietf.org>; Fri, 12 Jun 2015 10:09:28 -0700 (PDT)
Received: by qgg3 with SMTP id 3so13368243qgg.2 for <tls@ietf.org>; Fri, 12 Jun 2015 10:09:28 -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=+nfPEXLLnGjVTWEJIIQD43D7BURn9oAjyJ+T3PMuF5k=; b=lrZ0JjuebfhRjoZT/LXwyI7IklZfpjfpE7ryEiuYb3KaJUIL+USd/e9YsC6xmRCXa6 LVAxCNsc7Nc5W9RdJKLtta6OOr81PvN95BnYEKQda1StETbZpa5Fklxzm7OcTPG2GMco qIayEc5qj/sAfGALH1djxx43VWv1kfCjTrQOnXYqvCls6ge8jGsvvqX5y0BaKthqkf+i rr1Hr1zJaXSmg9Sp2VDa5OdVnbUV83TIJpTsVnlSPt78E8DVT4rmeSjR3a+8LE8owh4G o8GJL8P+OJzo0hyvCOOPioztZrFxy2DLp9UFBJGW7XwjnHETQOfJWiSNi0AxpgBhcPAW dwlQ==
X-Received: by 10.55.18.9 with SMTP id c9mr33316763qkh.50.1434128968166; Fri, 12 Jun 2015 10:09:28 -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 b31sm1927029qge.5.2015.06.12.10.09.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 10:09:27 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Fri, 12 Jun 2015 13:09:26 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201506111558.21577.davemgarrett@gmail.com> <201506121236.18304.davemgarrett@gmail.com> <20150612165558.GZ2050@mournblade.imrryr.org>
In-Reply-To: <20150612165558.GZ2050@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201506121309.26874.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0SPq39aLcVCnmCk7OS1D6zPNNP0>
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: Fri, 12 Jun 2015 17:09:35 -0000

On Friday, June 12, 2015 12:55:59 pm Viktor Dukhovni wrote:
> I still don't understand preclude as a matter of principle negotiation
> of ECDH_anon with AEAD if DH_anon with the same bulk cipher would
> be allowed.  Once we have separate negotiation of the key exchange,
> surely ECDH_anon can be one of the supported key exchange variants,
> and then take advantage of all the available bulk ciphersuites.

EC/FF may be negotiated separately, but a suite still needs to be selected. Anon cannot be negotiated via an ECDHE_ECDSA suite, as the signatures extension explicitly prohibits proposing anon alongside actual signatures. One way or another, anon needs its own suites to be used.

> Or does this proposal simply compress the client HELLO message,
> but the server is still ultimately selecting the same all-in-one
> ciphersuite (thus requiring Nico's new code points for ECDH_anon
> with AEAD)?

The server still needs to select a suite. If it selects an ECDHE_ECDSA suite, then it can negotiate EC/FF and RSA,DSA,ECDSA with extensions. It cannot negotiate anon. To do so would require either an ECDH_anon or DH_anon suite be negotiated. Yes, the preferred route is to require Nico's ECDH_anon codepoints for AEAD ciphers. With an ECDH_anon suite, the groups extension can be used to negotiate EC/FF. What I was stating earlier is that we could theoretically do so with DH_anon if we wanted to, but I would much rather the ECDH_anon draft be resurrected and passed as it would avoid confusion and the appearance of contradiction.


Dave