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

Nico Williams <> Fri, 07 December 2018 06:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88436124BF6 for <>; Thu, 6 Dec 2018 22:22:57 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 BvUgWVAW-xLr for <>; Thu, 6 Dec 2018 22:22:55 -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 05EEA12008A for <>; Thu, 6 Dec 2018 22:22:54 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 9E8C35C3574; Fri, 7 Dec 2018 06:22:53 +0000 (UTC)
Received: from (unknown []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 41EC45C2FB4; Fri, 7 Dec 2018 06:22:53 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.16.2); Fri, 07 Dec 2018 06:22:53 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Snatch-Shelf: 5ec0dea9492bd3db_1544163773486_3489291527
X-MC-Loop-Signature: 1544163773486:3742585764
X-MC-Ingress-Time: 1544163773485
Received: from (localhost []) by (Postfix) with ESMTP id E90E78031E; Thu, 6 Dec 2018 22:22:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=hMCtxlzLaRojG6 HjQixZvr3wsy0=; b=k5HCIxrhvPwMLTzn6dy7XSH7xdpMbVtNrV9bIci04wW8Up L8lsKSGc2XdOlM/eTe7K54FOij6fgzTbUWJn+6+OBKBnYhtBuvsXOK98M2vX1udo oTbaQ4LT30sykRzQXo9PW23Rnz5T+oVcc9h5g/7yge0myCRWLFj9+yNUcqWao=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 7A39A80316; Thu, 6 Dec 2018 22:22:51 -0800 (PST)
Date: Fri, 7 Dec 2018 00:22:47 -0600
X-DH-BACKEND: pdx1-sub0-mail-a80
From: Nico Williams <>
To: Daniel Kahn Gillmor <>
Cc: Stephen Farrell <>, "" <>
Message-ID: <20181207062246.GS15561@localhost>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefkedgleehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepuhgrlhgsvghrthgrrdgtrgenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
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:22:58 -0000

On Fri, Dec 07, 2018 at 03:37:25AM +0300, Daniel Kahn Gillmor wrote:
> On Wed 2018-12-05 18:59:07 +0000, Stephen Farrell wrote:
> > it's feasible and not easily defeated.
> TLS endpoints can share their data (key material, cleartext, etc) with
> whoever they choose -- that's just how the universe is implemented.
> They can even do it out of band, on a channel that the peer has no
> knowledge of.
> The question for TLS implementers is what to do about risks or leakage
> that they *can* become aware of.


> > 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;-)
> Yes, that would be great.  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.

False negatives are OK here.  False positives... depends on whether the
application / library can reconnect and retry.  (I doubt we'd add a TLS
extension by which the client can ask to retry with a fresher server eDH

When false positives are not OK a Bloom filter check prior to doing a
slower check that has no false positives is a good optimization.  But
let's assume the client can reconnect and retry, no?  If not then just
write all the eDH keys seen to a circular log and on Bloom filter
positive just do a linear search on the log.

Another possibility is to not fail on false positive but to mark a
server as "needs watching like a hawk" and use a more appropriate data
structure (w/o false positives) to watch it for a while.  When you catch
a server cheating with that data structure, then fail hard.

> Given that the size of the set of elements to include is effectively
> infinite, standard Bloom filters seem likely to be trouble (way too fast
> to converge onto false-positives).
> Perhaps "stable bloom filters" would represent a better tradeoff:


Another option is Scalable Bloom Filters.  Basically, when a filter gets
full-ish, you close it to additions and add a new filter, thenceforth
checking all the closed filters and the one open filter.  Delete filters
older than some number of days, and you limit storage use.

Looks like both Scalable and Stable BFs would fit the bill in terms of
limiting storage use and false positive rate.

> But hm, even a 0.1% false positive rate sounds pretty alarming too.  1
> in a thousand connections failing?  yikes!  I think we'd want to err on
> the false-negative side for this particular use case.

Depends on whether the client can retry, or whether you can do something
other than fail (see above).

> > 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.
> oof, CT itself is *really* heavyweight, and given our overall failure to
> get any sort of monitoring that would detect abuse by the CT logs
> themselves working (gossip hasn't had the necessary traction), i'm not
> sure i have the stamina to go down that route for ephemeral DH values.


> > 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.
> right, this would align with the bloom filter (or whatever)
> implementation guidance you mention above.  I've been thinking about
> this, and i'm not sure that we even need servername as part of the key.
> is there any reason that a client should ephemeral DH reuse *across*
> hosts?  If anything, ephemeral DH reuse across hosts *proves* that a DH
> secret has been shared (wittingly or unwittingly), which is one of the
> things we're trying to avoid, right?  Simpler implementations are
> probably better, and it's certainly easier to not deal with the
> servername.

You're right, the server name isn't needed.  In principle eDH keys
should be large enough and all randomly generated.  The chances of reuse
anywhere, ever, should be very small.

This would help detect RNGs with shared seeds.  Remember the bad RNG in
OpenSSL in Debian, about a decade ago?  Yeah, let's not have that happen