5 ms·

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

> 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.
- cbsmith 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. 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.
  - Dylan16807 8y ago
    When a server doesn't use forward secrecy, it looks like this: 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.

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.

cbsmith 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. 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.
- Dylan16807 8y ago
  When a server doesn't use forward secrecy, it looks like this: 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.