Kyle Rose <kr...@krose.org> writes: > On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen <bsnif...@akamai.com> wrote: > >> 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.
Yes, but it adds a storage requirement in proportion to the number of evil acts taken. For the same reason we find large-key cryptography interesting---now the adversary has to smuggle out megabytes---we might like this. > (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.) Yes: I'd expect a large operator to drop support for this extension under load, exactly when they switch to pre-generated ECDH keys. When they must further switch to re-used keys, that will be silent. Conversation elsewhere raises a practical point: browsers don't want to alert the user on every aborted connection. But a bad server can accept&send this extension, reuse a ECDH share, and then RST the connection rather than properly terminate it. All I can offer there is the idea that the client *should* alert when *it* closes the connection and doesn't get back a proof of proper key generation. -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
