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
--
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography