4 ms·

Forward secrecy is always useful for two endpoints that want to have a secure exchange of messages. It's a core component of secure transport these days. It's

by jaas 8y ago

Forward secrecy is always useful for two endpoints that want to have a secure exchange of messages. It's a core component of secure transport these days. 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.

unethical_ban 8y ago
Lack of PFS isn't a weakness. It isn't a mathematical backdoor. It's a config option that is left disabled when entities have a moral and ethical rationale for inspecting the traffic traversing their network.
DSingularity 8y ago
Which means this whole argument might be insincere and the real goal is otherwise.
cbsmith 8y ago
> 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. 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.
- avianlyric 8y ago
  > The whole point is to NOT trust the endpoints to be reliable narrators of what they are transmitting over the network 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.
  - cbsmith 8y ago
    > 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. 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.
- Dylan16807 8y ago
  Getting rid of forward secrecy doesn't fix the problem of server trust. A compromised server could always use a different private key. 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.
  - 8y ago

by jaas 8y ago

unethical_ban 8y ago

Lack of PFS isn't a weakness. It isn't a mathematical backdoor. It's a config option that is left disabled when entities have a moral and ethical rationale for inspecting the traffic traversing their network.

DSingularity 8y ago

Which means this whole argument might be insincere and the real goal is otherwise.

cbsmith 8y ago

> 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. 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.

avianlyric 8y ago
> The whole point is to NOT trust the endpoints to be reliable narrators of what they are transmitting over the network 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.
- cbsmith 8y ago
  > 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. 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.
Dylan16807 8y ago
Getting rid of forward secrecy doesn't fix the problem of server trust. A compromised server could always use a different private key. 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.
- 8y ago