Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Ted Lemon <[e-mail]>]

On Oct 25, 2017, at 3:34 PM, Nick Sullivan <[e-mail]> wrote:
> Forward secrecy with respect to other keys, like the session ticket key or other keys that can be generated centrally, are things that need to be looked at more closely for TLS 1.4 (or whatever’s next).

Unless I am very much mistaken, it is literally impossible to prevent a server from escrowing a key so that the contents of the communication can be decrypted.

> - having such a system on the internet is a bad idea because it reduces the security of multiple connections down to a single piece of data
> - on the other hand using draft-rhrd is safer than allowing organizations to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with non-forward-secret cipher suites

There's no question of allowing or not allowing—that's outside of IETF's sphere of influence.   But the case has been (to me convincingly) made that making it possible for an eavesdropper on the conversation to easily tell whether a client is willing to accept key escrow makes things worse, from a security perspective.

The main sense in which it makes things worse is that such a feature might be added to standard libraries, and thus be available at low cost, and thus might become easy to impose as a regulatory requirement.

This is why I have been advocating for simply not using TLS for this use case.   There exist solutions to this problem that do not require breaking TLS 1.3, that are standard, and that are already allowed for PCI compliance.   It's better for everyone if these two domains are kept separate, and I haven't yet heard a good argument for not doing so.

> The fundamental assumption of this draft is that that 3) is not feasible for all enterprises because rearchitecting their systems for a multi-key escrow is either too costly or that the requirement for TLS 1.3 will come too soon. Ted Lemon had some convincing arguments earlier about why enterprises should see this coming and invest in migrating to a model closer to 3),

To be clear, I actually don't think that per-session key escrow is feasible in the use case that we are talking about here.   From a security perspective I think it's a pretty good idea, because it allows for things like rate-limiting the number of connections that can be monitored, but from a practical perspective, arranging to have the keys available in a timely manner during debugging seems to me not to be tractable, since the number of keys involved would be substantial, and the timing would be quite exact; indeed, if the debugging process requires debugging all active streams in order to find an ID in the stream that is actually sought, I think it would be almost impossible, and certainly ludicrously expensive.

What I've been arguing for is to switch away from TLS for this use case.