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

Peter Gutmann <> Fri, 07 December 2018 06:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4112C126DBF for <>; Thu, 6 Dec 2018 22:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r2peOYDEVo_2 for <>; Thu, 6 Dec 2018 22:31:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BE8C124BF6 for <>; Thu, 6 Dec 2018 22:31:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1544164284; x=1575700284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qcgvHH0lO2UixKpdDaFMGm5BYBGijDE7kYKYVSZwNHg=; b=VTc8R05zXR3EvPt5/wlB6bKhHB4zrUYEiprsAj737ZofV8yQN2zBcHep CYY+E1cy2otVwSwIB511I4Z2rkKbo8/f/vel/OSEmkgqoKskUW3O67gCd S5PqnjnnZrZ1WBt3tqdhbk6s4s56YOMh4/yT2Ks5o/uHeh5CNg1F0kae2 OPg7ULjnCrTbJWf5HqBsBeuP1FKWtachGl7mB5nF7/VLNi9NpssTABLkm hxLAaPZUVVdYSahlee03aJPE2slhBHHnisvFra60J6s2Nhav3XhQz8WVM 2DdCjw2lW0guiCY407NLirfdueF/WRmfRQ0DpC6xybtbVCasCXdP+6Nou A==;
X-IronPort-AV: E=Sophos;i="5.56,324,1539601200"; d="scan'208";a="42367827"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 07 Dec 2018 19:31:22 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 7 Dec 2018 19:31:21 +1300
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Fri, 7 Dec 2018 19:31:21 +1300
From: Peter Gutmann <>
To: Daniel Kahn Gillmor <>, Stephen Farrell <>
CC: "" <>
Thread-Topic: [TLS] draft-dkg-tls-reject-static-dh
Thread-Index: AQHUjMy2+Ip4vOdFW02pqhJ3jndT6qVxloSAgAE690w=
Date: Fri, 7 Dec 2018 06:31:21 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [TLS] draft-dkg-tls-reject-static-dh
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Dec 2018 06:31:27 -0000

Daniel Kahn Gillmor <> writes:

>the way i was going to write it that guidance was pretty dumb (i was thinking
>of just a hashtable combined with a fixed-size ring buffer to be constant-
>space and roughly constant-time, and hadn't even considered bloom filters),
>so i welcome suggested text.

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.

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.