If you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.
It's not "useful" if your goal is to intercept and decrypt messages that are supposed to be secure, which is what both regulated entities and baddies want to do.
If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between whether that weakness is being exploited by regulated entities or baddies.
You don't need to weaken TLS in order to do what the regulated entities want to do - you just need to do the retention on the endpoints. The issue isn't that they can't do that, it's that they don't want to do that, probably for cost or convenience reasons. Those aren't reasons to weaken TLS for everyone who actually wants secure comms.
Weakness in the protocol, but not necessarily weakness in the system as a whole. This is an environment where part of the trusted nature of the system comes from having a complete record of all the network communication to and from the system, and an ability to audit that data offline.
That context is in conflict with the objectives of PFS & TLS 1.3 in general. So, understandably, they came up with another solution that fit the design goals, and understandably, rather than reinvent the wheel, they came up with a way to tweak existing solutions to fit their design goals.
> You don't need to weaken TLS in order to do what the regulated entities want to do - you just need to do the retention on the endpoints.
Yeah, you're not understanding the system. The whole point is to NOT trust the endpoints to be reliable narrators of what they are transmitting over the network (which makes sense, because if they are compromised, they wouldn't be). TLS is designed to allow two trusted endpoints to communicate, but the goal/context for eTLS is to have a full audit of communications into and out of an untrusted node. That's presumed from the start; TLS's goals therefore aren't helpful.
That’s not the goal though. You’re not trying to monitor the systems themselves, you’re trying to monitor the people using the system.
A financial regulator doesn’t give a crap what your system does, or how it does it. They only care that they can blame (and potentially prosecute) an actual person if it goes wrong.
Using middleware boxes makes this easy. Not need to actually modify the software your using to create proper audit logs, just log everything and figure it out later.
From a systems perspective, they aren't logically different.
> A financial regulator doesn’t give a crap what your system does, or how it does it. They only care that they can blame (and potentially prosecute) an actual person if it goes wrong.
Yeah, you tell that to the regulator when it becomes clear that trades were being published to a competitor a millisecond before they were being listed.
> Using middleware boxes makes this easy. Not need to actually modify the software your using to create proper audit logs, just log everything and figure it out later.
The log everything part, you are totally right about. The "middleware" box that actually is part of the operational path... that's a different story. You want something that watches the system without actually being part of the system.
The only way to truly not trust the server is to verify that you can decrypt in real time.
But wait, if you're verifying that you can decrypt in real time, then you could apply that to forward-secret connections too! Have the server send session keys to the logging machine, and make it test them.
It requires a (small) modification to the server, but so does using your own protocol.
Yes, but what it solves is that when it does so, you know it has been compromised.
> The only way to truly not trust the server is to verify that you can decrypt in real time.
No. That is the way to know that you can not trust the server in real time. That isn't the objective. The objective is to be able to, after the fact, prove that you could trust it at that point in time.
While it's working correctly (which involves you knowing the private key), you know everything it sends. If it gets compromised, it might keep using the same key and you know what it sent, or it might start using a different key and you'll never figure out what it sent while compromised.
When a server does use forward secrecy, it looks like this:
While it's working correctly (which includes logging session keys), you know everything it sends. If it gets compromised, it might keep logging session keys and you know what it sent, or it might start logging fake keys and you'll never figure out what it sent while compromised.
What meaningful difference is there?
You don't trust the server to tell you what it sent. You record what it sent, and at some point you can check if it decrypts or not. This acts the same whether or not you have FS enabled.
> The objective is to be able to, after the fact, prove that you could trust it at that point in time.
You can verify what it sent, but that doesn't prove it wasn't compromised.
There would not be a meaningful difference in terms of being able to tell if it was compromised. There would be a meaningful difference that you would now have an operational exposure of the session keys, that fundamentally undermines not just PFS but potentially the encryption protecting the session in general.
> You can verify what it sent, but that doesn't prove it wasn't compromised.
You're right. The semantics of what you are trying to prove isn't so much that it wasn't compromised, but rather to verify that there wasn't some kind of leakage of data from the system, which is a subtly different thing.
That's no worse than before, where you could use the private key to undermine the encryption.
You could also end up with a much better system if you encrypted the session keys so that only the auditing device can decrypt them.
>
> You could also end up with a much better system if you encrypted the session keys so that only the auditing device can decrypt them.
We're speculating about the trust model and the constraints it must operate within. The private key isn't getting transmitted continuously over the network, so perhaps with some trust models transmitting session keys is equivalent, better, or worse.
Given that the people actually working in the space have clearly put a lot of thought into how to best fit their needs, I wouldn't presume that they got it wrong.
If they're actually recording the entirety of every TCP stream that comes into the datacenter, how many sets of credentials do you think are stored in that system? And right now, they're all encrypted with a single or small number of keys, that must be available to the system that is storing and parsing this data.
Also, given the breaches that have happened, I keep waiting for there to be a set of regulations from the other side requiring adequate protection and deletion of data. He seems entirely unconcerned with that aspect.