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

[Daniel Kahn Gillmor <[e-mail]>]

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.

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:

  http://webdocs.cs.ualberta.ca/~drafiei/papers/DupDet06Sigmod.pdf

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.

> 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.

If someone wants to try to think that through (how do you ensure it's
not spammed?) i'd be happy to see it as a separate draft, but i don't
think it belongs in this one, which is intended as guidance for TLS
endpoint implementations.

> 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.)

Yes, that's absolutely right.  Proposals for text welcome!

> "MUST avoid accidental" is an interesting phrase:-)

good catch, i'll drop "accidental" :)

> 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.

        --dkg