On Wed, Dec 05, 2018 at 06:59:07PM +0000, Stephen Farrell wrote: > My main concern is that a server playing a > draft-green-like game could just choose DH > values more cleverly and avoid detection.
We can forbid static server DH keys, and should attempt to preclude them by encouraging clients to do _some_ work to detect them. We can preclude Dual_EC style escrow systems by not providing a way to publish enough material on the wire for an eavesdropper with access to the Dual_EC secrets to recover the keys. Dual_EC style escrow systems are not protocol-neutral. We can forbid extension/ciphersuite registration for key escrow schemes. We'd have to direct experts designated for Expert Review to look for the possibility that an extension or ciphersuite could be used for in-band key escrow. But we can't preclude protocol-neutral (out-of-band) key escrow schemes. These are not detectable (implementation fingerprinting can always be defeated). > 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.) Such a scheme requires some sort of counter to appear on the wire, similar to Dual_EC. With no nonces, this can't be done. But with small enough counters it will be difficult to preclude their appearance (or the appearance of a truncated counter, which would require some brute force on the part of the escrow agents, again like Dual_EC) as there will always be freedom to express some small number of arbitrary bits in-band. > 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;-) OK, but clients would have to share...: > 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. Providing a way for clients to report what they see would have serious privacy concerns that, IMO, outweigh the static server DH key concerns. And none of this would help detect/preclude out-of-band escrow systems. Client-side detection of static/reused server DH keys will simply push server operators who must escrow to use undetectable out-of-band escrow, thus wasting all work on client-side detection. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
