4 ms·

> Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that sh

> Why not have the endpoints ship their session keys OoB to a centralized place / whatever needs to look at the traffic? Sure, there's more of them, but that shouldn't be a huge volume? (It is insignificant compared to the captured traffic.) When you have communication between two endpoints, over your own network, transmitting session keys OoB doesn't improve the security of your systems, but does increase the complexity. > And I am not sure if you're attempting to address this, but instead of terminating at a more edge-ish node, why not just decrypt and re-encrypt there? Aside from adding a ton of latency and extra performance overhead, you now have a new operational endpoint that you have to trust. That doesn't fit the trust model. They key point here is the data is getting logged and then decrypted offline, by a totally separate system.

bmm6o 8y ago
Not to mention that you have to trust the endpoint to ship their session keys. If one "forgets" or the key is "lost in the mail", there's no way to prove that message wasn't problematic.
- deathanatos 8y ago
  Assume that non-PFS ciphersuites had remained in TLS: You still have to trust the endpoint to not negotiate a PFS ciphersuite.
  - cbsmith 8y ago
    Yes, but a failure to do so would be considered a compromise, as opposed to a simple network failure.
deathanatos 8y ago
> doesn't improve the security of your systems Having PFS increases security for your end users. (Minus your storing of the session keys, of course; if whatever you need the session keys for doesn't require you to store them forever, then it still seems like a benefit.) Being able to use standard, well-audited libraries instead of a proprietary piece of "enterprise" code is a benefit. > Aside from adding a ton of latency and extra performance overhead The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware. > you now have a new operational endpoint that you have to trust No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.) If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.
- cbsmith 8y ago
  > Having PFS increases security for your end users. The context of ETS/eTLS is that you yourself are the end user. > The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware. Uh-huh. I like that you believe that, but with a lot of HFT systems, even the latency of going from the NIC to the CPU is too much. Adding a hop in between that decodes and then reencodes, the the inherent buffering involved, is way, way too much latency. > No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.) > > If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3. Yeah... see, that's the part you aren't getting. The old model was also not terminating through a proxy with TLS 1.2. That actually doesn't address the needs of the trusted system.

bmm6o 8y ago

Not to mention that you have to trust the endpoint to ship their session keys. If one "forgets" or the key is "lost in the mail", there's no way to prove that message wasn't problematic.

deathanatos 8y ago
Assume that non-PFS ciphersuites had remained in TLS: You still have to trust the endpoint to not negotiate a PFS ciphersuite.
- cbsmith 8y ago
  Yes, but a failure to do so would be considered a compromise, as opposed to a simple network failure.

deathanatos 8y ago

> doesn't improve the security of your systems Having PFS increases security for your end users. (Minus your storing of the session keys, of course; if whatever you need the session keys for doesn't require you to store them forever, then it still seems like a benefit.) Being able to use standard, well-audited libraries instead of a proprietary piece of "enterprise" code is a benefit. > Aside from adding a ton of latency and extra performance overhead The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware. > you now have a new operational endpoint that you have to trust No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.) If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.

cbsmith 8y ago
> Having PFS increases security for your end users. The context of ETS/eTLS is that you yourself are the end user. > The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware. Uh-huh. I like that you believe that, but with a lot of HFT systems, even the latency of going from the NIC to the CPU is too much. Adding a hop in between that decodes and then reencodes, the the inherent buffering involved, is way, way too much latency. > No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.) > > If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3. Yeah... see, that's the part you aren't getting. The old model was also not terminating through a proxy with TLS 1.2. That actually doesn't address the needs of the trusted system.