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

R duToit <> Wed, 05 December 2018 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98E0E130ED7 for <>; Wed, 5 Dec 2018 11:20:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9HeNbTxf3xeN for <>; Wed, 5 Dec 2018 11:20:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D15DC130E13 for <>; Wed, 5 Dec 2018 11:20:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1544037599; cv=none;; s=zohoarc; b=b14ykIuZNzNGSNaaRIaqEm2XAhedlLKENQk5VBBNAXjIgxtBeVt+0rK+vGXDthFNcyGKqpqeI2MGgMdKN7ywf/CgbtRzcnNIKqPLkMEnuEmhyn0ydjvgejjWz+hNb4v/HNVFV04p337br14MY9gGScKdZYuigJbpk2P+FzCkEvA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1544037599; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=Pc7ORStH2LzXEftXupTI7e+FUyY1SwBgWUlg3KucdQQ=; b=bsKDq/mRBA75I6qZQ8bjeSQ0IGO/AE4P+3Q7GhkWPn2kImvPkvXbxDzu9PXM/ZT0CurVlmxEmPx8XSsGzBjqP4eb4JF29u3yQwHs5SUT8CUcSkDDgM/aE/RwDeInWCCEtF0a4pYCDQnTVNcrZdWmfJNNCN59QOh0JQsCUW4aNt4=
ARC-Authentication-Results: i=1;; dkim=pass; spf=pass; dmarc=pass header.from=<> header.from=<>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1544037599; s=zoho;;; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=6792; bh=Pc7ORStH2LzXEftXupTI7e+FUyY1SwBgWUlg3KucdQQ=; b=Z4wIpCru616TZRfymsJBCg3zBROYP8APhPs27Z04OLz3+kCm8Vy3MZ7Nw4Gj0cUf F/s1mHP2dbFZLOrR53KmscKGRL2Q8dUt9pl49YG6AleZu9iVwPf4K8vJuvR/qwmTYOa +Zy49+XWKPf0fjOmJvn/yuj4HB3+yS49fqwBpmLw=
Received: from by with SMTP id 1544037597972163.83900577562906; Wed, 5 Dec 2018 11:19:57 -0800 (PST)
Date: Wed, 05 Dec 2018 14:19:57 -0500
From: R duToit <>
To: "Stephen Farrell" <>, "" <>
Message-Id: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_999975_1451935658.1544037597970"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
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: Wed, 05 Dec 2018 19:20:04 -0000

See Quote:  "As we will discuss later, we empirically find that at least 7.2% of HTTPS domains in the Alexa Top Million reuse DHE values and 15.5% reuse ECDHE values." ---- On Wed, 05 Dec 2018 13:59:07 -0500 Stephen Farrell <> wrote ---- Hiya, Thanks for writing this, I would support it being progressed if we conclude that it's feasible and not easily defeated. My main concern is that a server playing a draft-green-like game could just choose DH values more cleverly and avoid detection. E.g. if the DH values are derived via some function so that public shares never recur, or only rarely. (And while such derived DH values would in a sense represent the server borking its own crypto, that's basically what draft-green suggested anyway, so one might expect a DH borking adversary in such cases to not care so much about the client's security.) I guess that testing would also be an issue so it'd be great if someone was to try do that to check if this might break things. (Which'd be useful in any case if it found some servers accidentally re-using.) Other than that, some more minor comments: It'd be good to describe in detail a way in which one might efficiently retain the client state required, e.g. via a bloom filter maybe? (Assuming an occasional false positive isn't too alarming;-) It might also be good to outline how a survey or CT-like mechanism (say logging some value as a witness for the DH public) could be used to detect this kind of badness even if common TLS clients didn't deploy. I think in 3.2 you need to be a bit more precise about which DH values you mean, e.g. if doing ESNI then clients will see the same DH value from ESNIKeys a number of times. (So I suspect you couldn't implement this at a very low level in the crypto engine.) "MUST avoid accidental" is an interesting phrase:-) Section 4 could probably do with some text about how not to do this, e.g. keeping a list of {servername,[DH values]} would be bad if a client's disk were compromised. Cheers, S. _______________________________________________ TLS mailing list