On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen <bsnif...@akamai.com> 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. > > 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. > Of course, this is precisely the point. All your proposal does is complicate the process of sharing sessions with a third-party: it doesn't stop an endpoint from surreptitiously doing evil. (Your proposal is interesting, but because it neatly solves the problem of DH share reuse without requiring some kind of CT-like infrastructure, not because it somehow addresses the evil endpoint problem. On the downside, it also may have implications for amplification DoS.) Kyle
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
