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. Then the client has an opportunity to notice---this session didn't have a (retrospective) proof of proper generation of the server ECDH share, and so may involve key reuse in a dangerous way. This doesn't stop the server from logging the session key, of course. I *think* the shape I describe above fits into an extension, so (a) it doesn't have to be done to ship TLS 1.3, and (b) it can be available for use in general purpose browsers, and then disabled for the "enterprise" case, and (c) I don't have to worry through the performance implications of not being able to pre-generate a stack of ECDH shares. -Brian -- Brian Sniffen <bsnif...@akamai.com> Information Security: Safety, Adversarial Resilience, Tools, Compliance /(* Akamai - Faster Forward _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
