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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
