TLS 1.3 deliberately doesn't have RSA kex (key exchange using the RSA public key encryption system) which was obsolete.
All TLS 1.3 key agreements will thus be based on information chosen by both parties, which enables Forward Secrecy.
The people this work is addressing (like big banks) are often part of EDCO (Enterprise Data Center Operators) who tried to get RSA kex put back into TLS 1.3. They failed largely because the IETF isn't a democracy. We aren't a government, we do not believe in Kings, or Presidents, or Voting. We do engineering here, we believe in rough consensus and running code. They also failed because of IETF Best Common Pratice #188, "RFC 7258 : Pervasive Monitoring Is an Attack" which says the IETF should design protocols to resist this stuff.
Appreciate this overview and absolutely adore the mentality of "rough consensus and running code", BAMFs. It's a shame that NIST, who is supposed to use their data to establish security best practices is expending resources to defeat them(though I guess this isn't our first rodeo in this vein); thank you IETF engineers for being sane custodians of actual security.
People are going to do this, so for an outfit like NIST the question is about harm minimisation.
Harm minimisation is why you'd have a place where junkies can get clean needles rather than sharing used needles. If you don't like the junk example, how about booze? Americans tried making it outright illegal, didn't go well, but now they have a lot of rules. The rules make the booze not safe - booze is poisonous, but at least less dangerous than it might have been, with fewer inadvertent casualties, less associated crimes, and so on.
Sure, I can see the harm minimization angle, I guess I just view it like a lot of other gov-promoted weakening of security under a purported harm minimization.
Reading through the RFC you referenced ends with this interesting conclusion:
Making networks unmanageable to mitigate PM is not an acceptable outcome,
but ignoring PM would go against the consensus documented here. An
appropriate balance will emerge over time as real instances of this
tension are considered.
Perhaps this is one of the first instances of this tension, at least re: tls1.3? It also doesn't seem that the IETF is quite as uninterested in considering provisions around network management...
I find that a bit unfortunate as network management has a long history of think-of-the-children harm mgmt style abuses. Hopefully this mainly means that they're willing to design protocols in a way that facilitate management without weakening them to PM attacks.
The idea that NIST is trying to weaken cryptography by regularizing TLS intercept at banks is tinfoil hat stuff. Not only were banks already doing this, but they literally tried to halt TLS 1.3 and re-add RSA key agreement to keep doing it. NIST is trying to minimize harm here.
I mean, it's not that tinfoil hat as the DRBG debacle showed.
But I'm not talking conspiracy here, I just feel like providing a 5 volume tech manual on how to do pervasive monitoring under TLS1.3, no matter their stated justification, is antithetical to their purported mission.
All TLS 1.3 key agreements will thus be based on information chosen by both parties, which enables Forward Secrecy.
The people this work is addressing (like big banks) are often part of EDCO (Enterprise Data Center Operators) who tried to get RSA kex put back into TLS 1.3. They failed largely because the IETF isn't a democracy. We aren't a government, we do not believe in Kings, or Presidents, or Voting. We do engineering here, we believe in rough consensus and running code. They also failed because of IETF Best Common Pratice #188, "RFC 7258 : Pervasive Monitoring Is an Attack" which says the IETF should design protocols to resist this stuff.