I didn't want to stick my foot in this, but here we are. The goal for an inspection service to be able to take a recording of the network and a key (or corpus of keys) and be able to decrypt any TLS connection to a server within that network.
There are multiple ways of getting these keys. 1) use TLS 1.2 with RSA -> one single key 2) use TLS 1.3 with DH key derived from seed -> one single key (similar to draft-green) 3) use any version of TLS and export the session keys -> corpus of keys equal to number of connections 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), which will always be possible in a system that uses symmetric cryptography for encryption. Newer companies like the one mentioned by Tony Arcieri have managed to architect their systems this way, so it’s not impossible. Still, it’s usually cheaper to adapt an existing system rather than re-architect your network (and buy more gear). As long as 2) is possible, the moving to a model based on 3) is going to be a hard sell. Given that enterprises would rather be standards-compliant, this draft is a way to prevent enterprises from just going ahead and implementing 2), and instead implement something that has similar benefits (a single master key that can decrypt multiple connections), but with additional safeguards for the user: -the ability to opt out -visibility into the fact that their connection is part of a pool of connections protected by a single key You can do neither with 2). This is a win. To Rich’s argument that network domains will force browsers to implement this by blocking connections that don’t advertise this support, I disagree. There are no passive firewalls that I know of that drop TLS connections that don’t support escrow (in the sense that non PFS-RSA and session ticket keys in TLS 1.2 are escrow). Shouldn’t these be blocked by the GFW if someone is forcing RSA escrow? On that note, so what if some browsers opt in? Servers need to also opt-in to setting visibility keys. These will be visible by the browser, and visible by network watchdogs. Visibility is good in the situation where both parties want to be honest, and a dishonest escrow mechanism is possible. Furthermore, large services that are internet-facing that see this extension existence can simply disconnect when it's presented, applying back-pressure in the event of this "escaping" the datacenter. Until TLS is redesigned so that a single key escrow is not possible, datacenter operators will choose to do 2). For the next version of TLS, we should strive to eliminate a the ability for a server to escrow a single key. I posit that this should be a fundamental design principle for TLS going forward: *cross-connection secrecy*. Forward secrecy with respect to the long term certificate key is something that has been addressed in TLS 1.3. 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). This draft is an optional extension that allows a client and server to agree that a single key held by the server should be able to decrypt the data of multiple connections. I don’t think it’s something that belongs on the Internet as a whole, but understood it as a lesser of two evils with respect to the options people have. To summarize: - TLS 1.3 allows single-key escrow with no client opt-in by design (because of ephemeral DH) - This is something that requires fundamental changes to TLS to fix, but should be looked into - Enterprises should look into moving to a model where session keys are exported to prepare for this eventuality - draft-rhrd allows clients to opt-in to an extension-based escrow system that doesn’t abuse the core protocol and it enables network watchdogs to observe - 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 Nick On Thu, Oct 19, 2017 at 7:26 AM Salz, Rich <rs...@akamai.com> wrote: > > > I didn’t say easy, I said ‘easier’ > > > Can you explain how it is easier? > > There’s no way to limit it to the use-case it was putatively intended > for. We now have a signaling mechanism that says “allow interception.” > Firewalls can drop connections where the client doesn’t send that > extension. Therefore they can force only tappable TLS traffic. This makes > the job easier. > > I take it you want to see this draft adopted? > > > _______________________________________________ > 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
