Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Nico Williams <[e-mail]>]

On Tue, Dec 04, 2018 at 04:34:08PM +0100, Jonathan Hoyland wrote:
> Is it necessarily true that any key escrow system must allow resumptions?
> 
> Just to play devil's advocate, consider defining a new cipher suite that
> appended a MAC to each message before applying one of the other cipher
> suites.
> If the MAC is keyed with a key not derived from the master secret, but from
> some other value shared between the client and server, but not the
> middlebox, then the middlebox would be able to read all* the traffic, but
> would not be able to successfully resume the session.

This MAC key would also have to be involved in the session resumption
PSK, but yes.  You don't even need this extra MAC past the handshake,
you just need an extra key not known to the escrow agent for use in the
session resumption PSK.  (The extra MAC on every record would impose too
much overhead.)

> *The middlebox would not be able to verify the tag, so technically it can't
> check /everything/, but it would be able to read the data on the channel
> without being able to modify it.

Oh sure, if you're willing to do such violence to TLS, then yes, it can
be done.

However, a constraint here is that an escrow design can't really require
client-side modifications without the IETF approving of it and the
client implementations accepting the change.

The most obvious escrow design requiring no changes to the clients is to
use a static eDH key on the server-side.  The next most obvious such
design is to have the server talk to the escrow agent.

Nico
--