Re: [TLS] draft-dkg-tls-reject-static-dh

Nico Williams <nico@cryptonector.com> Fri, 07 December 2018 06:47 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147061277C8 for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 22:47:55 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 WWc4Xl9nBNK9 for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 22:47:53 -0800 (PST)
Received: from firebrick.maple.relay.mailchannels.net (firebrick.maple.relay.mailchannels.net [23.83.214.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565F7126DBF for <tls@ietf.org>; Thu, 6 Dec 2018 22:47:53 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4FDA63E432F; Fri, 7 Dec 2018 06:47:52 +0000 (UTC)
Received: from pdx1-sub0-mail-a80.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DF4433E3D89; Fri, 7 Dec 2018 06:47:51 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a80.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 07 Dec 2018 06:47:52 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Cold-Obese: 0cd0d6226a9a4daa_1544165272160_2340212396
X-MC-Loop-Signature: 1544165272160:3819652240
X-MC-Ingress-Time: 1544165272160
Received: from pdx1-sub0-mail-a80.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTP id A531F80329; Thu, 6 Dec 2018 22:47:51 -0800 (PST)
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=QQ7rsBna5clb5h Ys6v9lM+eALhE=; b=B0CCZSfWwHWUq9157jXK7csEx5a+HcvvzUZliKPH5BJit/ mtDkyCswNkzz42dqtDXRGpjTjTJiEqASJ+BcXKaBnYBZli+qAeNkgYLLR+0jEooB XXy4063tkxmWeSy88eMD/HpiL7KuTeS2v6AQcQQDmvVTukq9faeXhDCHYbn4U=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTPSA id BCCD880328; Thu, 6 Dec 2018 22:47:47 -0800 (PST)
Date: Fri, 07 Dec 2018 00:47:45 -0600
X-DH-BACKEND: pdx1-sub0-mail-a80
From: Nico Williams <nico@cryptonector.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20181207064745.GU15561@localhost>
References: <9a9be8fb-9667-0c6a-9fac-cc167f94599f@cs.tcd.ie> <874lbqcgu2.fsf@fifthhorseman.net> <1544164274460.61998@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1544164274460.61998@cs.auckland.ac.nz>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefkedguddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kCY8WgFrWetJDE9JAbs2C2N7hQ8>
Subject: Re: [TLS] draft-dkg-tls-reject-static-dh
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 07 Dec 2018 06:47:55 -0000

On Fri, Dec 07, 2018 at 06:31:21AM +0000, Peter Gutmann wrote:
> Aren't you going to get into an adversarial machine learning problem where
> your recogniser has to be smarter than the other side's DH-reuse code?  In
> other words if the server just reuses the same DHE public value again and
> again you can detect it, but if they generate slightly different values from a
> fixed seed or start point you're not going to be able to detect it unless you
> know what they're doing.

If it's different then that's costing the server the resources to
generate it, which is precisely what its operator didn't want when they
enabled eDH key reuse.

Indeed, the client cannot detect the use of a fixed seed and counter
shared with an escrow agent.

> Not to mention a NOBUS DHE public value if they really want to be crafty.  In
> other words if someone wants to middlebox TLS, they're going to do it no
> matter how much people may dislike it.

No argument there.  There's nothing wrong with server-side key escrow if
that's what the server operator wants.

Nico
--