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.
*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.
Regards,
Jonathan
On Sun, 2 Dec 2018 at 23:36 Nico Williams <n...@cryptonector.com> wrote:
> On Sat, Dec 01, 2018 at 07:59:45AM -0800, Tony Arcieri wrote:
> > This does not seem to address a problem which was brought up when the
> > similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> > system in possession of one of the non-ephemeral-ECDHE private keys,
> > ostensibly for the purposes of passive traffic decryption, can
> arbitrarily
> > resume decrypted sessions and therefore impersonate any observed clients.
> >
> > I'm not a fan of systems like this, but I believe for security reasons
> they
> > should be designed in such a way that only the confidentiality of traffic
> > is impacted, and a "visibility" system isn't able to leverage the
> decrypted
> > traffic to resume decrypted sessions and thereby impersonate clients.
>
> Any key escrow system will have this property. Given the session keys
> (or a way to recover them) you can resume decrypted sessions.
>
> If I had to I would build a corporate TLS 1.3 session key escrow system
> as follows:
>
> - use a keyed PRF/PRNG to generate the ephemeral DH keys, with two
> inputs, a secret key shared with the escrow third party, and a number
> generated randomly:
>
> edh_key = DH_key_gen(seed = PRF+(escrowed_key, r = getrandom()));
>
> - log to the escrow third party {connection ID, random} for each
> connection (the connection ID can be a handshake transcript hash).
>
> (it's even safe to log the random number r in the clear, as it alone
> is insufficient for recovering session keys)
>
> This would preserve all the properties of TLS 1.3 and would work for any
> other version of TLS with EDH too, and also for any other protocols that
> use ephemeral key agreement (SSHv2, IKE, ...).
>
> It's more work to integrate this than to use RSA key transport with
> escrowed RSA key orchestration, but it's one-time work (do it for about
> six or so open source implementations and you've got 90+% coverage).
>
> I'm sure upstreams would accept this sort of contribution as it is
> better for everyone outside corporate environments if we can just stop
> the pressure to go back to RSA key transport. It's also better for
> corporate environments, as insiders are the largest threat there, so
> forward security is still a plus even in corporate environments.
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
