On Mon, Jul 24, 2017 at 10:03:28AM -0400, Brian Sniffen wrote: > Ted Lemon <mel...@fugue.com> writes: > > > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL > > <u...@ll.mit.edu> wrote: > >> What I am trying to avoid is the ability to *surreptitiously* subvert a > >> protocol that’s assumed to be secure. > > > > You don't seem to be hearing what I'm trying to say. What you are > > proposing is physically impossible. > > Is it? I could imagine making the server ECDH share dependent on the > client ECDH share, plus a local random value. At the end of the > session, the server discloses that random value, showing that it > properly constructed a fresh ECDH share.
I do not think this works. As a blatant example, have server generate the ServerRandom and then the ECDH seed using Dual-EC-DRBG... The ECDH share will then change every connection and there is a seed to demonstrate, but the connections can still be decrypted by who controls the Dua-EC-DRBG backdoor key. Yes, Dual-EC-DRBG is quite crappy with sizable biases, but discovering those would take way too many connections. And there are similar methods that have much much smaller biases. Basically, if implementation wants to be secretly evil, it can be secretly evil, and there is nothing you can do to discover it remotely. Bad implementations are a separate problem. E.g., repeating the same DH share for a long time because there is no key rotation. That sort of behavior is pretty blatant if one monitors the DH shares used. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
