The biggest difference I'm aware of is TLS 1.3 encrypts the initial handshake[0] in a way to prevent eavesdropping the hostname of the destination. Prior to that, you could get the hostname via network monitoring if you wanted. Encrypting the TLS handshake didn't maker sense to prioritize though as DNS requests were sent in the clear.
However with DNS increasingly being encrypted with DoH and DoT, the TLS handshake was one of the only places you could eavesdrop on the destination hostname, until it was removed in 1.3.
Of course network monitoring will still give you the destination IP, but those are increasingly overwhelmingly destined for a major cloud or CDN provider which doesn't provide much context about the actual destination.
If you'll forgive the shameless self-promo, I covered a decent amount of this in my Blackhat talk about encrypted DNS a few years back: https://www.youtube.com/watch?v=XCnE2o2pfxs
As you can see this ID currently has "WG state In WG Last Call" which means the Working Group were asked if they have any final stuff that needs changing. After this it could enter a state where it needs word smithing, or it could even just get sent to the IESG and then there's an opportunity for the wider community to chime in.
[Keep in mind though, the IETF's RFCs don't dictate what gets done, we're agreeing engineering documents here, the implementations do in fact already exist and are in use for some systems, they might change to adopt any hypothetical change in the final RFC, or equally the RFC might be wrong, there's one for how HTTP Cookies should work and it describes how a working group decided they should work - but they just kept working the way they had before anyway]
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.
(I tried eying through the OP but my eyes started bleeding from all the corporate IT jargon.)