Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ilari Liusvaara <[e-mail]>]

On Mon, Jul 24, 2017 at 10:03:28AM -0400, Brian Sniffen wrote:
> Ted Lemon <[e-mail]> writes:
> 
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <[e-mail]> 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