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

[Brian Sniffen <[e-mail]>]

Kyle Rose <[e-mail]> writes:

> On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen <[e-mail]> 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 <[e-mail]>
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward