7 ms·

It’s worth reading the mailing list posts by BITS (the main proponent of ETS) here: https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2ScdPZ8E08RE https:

It’s worth reading the mailing list posts by BITS (the main proponent of ETS) here: https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2ScdPZ8E08RE https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2Sc.... The replies are pretty informative. You can see here the message in which BITS starts to consider fixed DH keys, which were implemented in ETS: https://mailarchive.ietf.org/arch/msg/tls/3d7TM0g_EdtMzhgmcPn_Xb-ZFjY https://mailarchive.ietf.org/arch/msg/tls/3d7TM0g_EdtMzhgmcP... > Tue, 27 September 2016 18:21 UTC > The various suggestions for creating fixed/static Diffie Hellman keys raise interesting possibilities. We would like to understand these ideas better at a technical level and are initiating research into this potential solution. The core argument made by BITS is that they need a way to log TLS traffic such that it can be decrypted later, in order to provide data retention in line with regulations. While this could be done by logging all ephemeral keys generated by the servers, BITS argues that this isn’t practical due to their use of dedicated packet logging hardware that is key-ignorant. Instead they want to use non-forward-secret TLS so they can decrypt past messages easily. Their beef with TLS 1.3 is that it removes all non-FS key exchange methods, and further that by explicitly obsoleting TLS 1.2 as a standard pushes them to have to adopt 1.3 in an enterprise environment (or risk current/future regulatory scrutiny over their use of an obsoleted standard). Hence why they want to develop a competing, active standard with non-FS key exchange.

cbsmith 8y ago
If you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.
- 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.
- curryst 8y ago
  I disagree, it still protects the encryption of information they have in flight. 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.
devy 8y ago
I've read Andrew Kennedy's email. This line hits the point for me. His argument is reasonable, sometime it's impractical or hard or costly or all the above to upgrade all the systems to meet regulatory compliance and the newer and stricter and safer security standards. It is vital to financial institutions and to their customers and regulators that these institutions be able to maintain both security and regulatory compliance during and after the transition from TLS 1.2 to TLS 1.3. One example of that is the NIST's recommendation on password policies. Most of the time the regulatory mandates are outdated and it's hard to bring them up to speed, in the mean time, as a financial institution you simply cannot have your IT system incompliant, even that means having a less security practice.
- avianlyric 8y ago
  > as a financial institution you simply cannot have your IT system incompliant This just isn’t true, or rather “compliance” tends to be quite fuzzy. Regulators generally expect you follow recommendations from places like NIST. But it’s not a hard requirement, you just need to explain why deviating is better. Unfortunately most fincial institutions trip up at the “explain why it’s better” bit. Either because they aren’t competent enough, or (more likely) can’t be bothered.
  - zamadatix 8y ago
    If something was better for the entire industry one would think the compliance recommendations would be the topic of discussion, not explaining why it needed to be done differently individually.
- dagenix 8y ago
  I'm not sure what you are getting at with the NIST example - their recommendations for passwords are pretty reasonable. Maybe their older ones weren't, but, their newer guidelines recommend against outdated ideas such as expiring passwords. (https://pages.nist.gov/800-63-FAQ/#q-b5 https://pages.nist.gov/800-63-FAQ/#q-b5)

cbsmith 8y ago

If you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.

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.
curryst 8y ago
I disagree, it still protects the encryption of information they have in flight. 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.

devy 8y ago

I've read Andrew Kennedy's email. This line hits the point for me. His argument is reasonable, sometime it's impractical or hard or costly or all the above to upgrade all the systems to meet regulatory compliance and the newer and stricter and safer security standards. It is vital to financial institutions and to their customers and regulators that these institutions be able to maintain both security and regulatory compliance during and after the transition from TLS 1.2 to TLS 1.3. One example of that is the NIST's recommendation on password policies. Most of the time the regulatory mandates are outdated and it's hard to bring them up to speed, in the mean time, as a financial institution you simply cannot have your IT system incompliant, even that means having a less security practice.

avianlyric 8y ago
> as a financial institution you simply cannot have your IT system incompliant This just isn’t true, or rather “compliance” tends to be quite fuzzy. Regulators generally expect you follow recommendations from places like NIST. But it’s not a hard requirement, you just need to explain why deviating is better. Unfortunately most fincial institutions trip up at the “explain why it’s better” bit. Either because they aren’t competent enough, or (more likely) can’t be bothered.
- zamadatix 8y ago
  If something was better for the entire industry one would think the compliance recommendations would be the topic of discussion, not explaining why it needed to be done differently individually.
dagenix 8y ago
I'm not sure what you are getting at with the NIST example - their recommendations for passwords are pretty reasonable. Maybe their older ones weren't, but, their newer guidelines recommend against outdated ideas such as expiring passwords. (https://pages.nist.gov/800-63-FAQ/#q-b5 https://pages.nist.gov/800-63-FAQ/#q-b5)