What’s the crucial difference between TLS 1.2 and 1.3 here?
(I tried eying through the OP but my eyes started bleeding from all the corporate IT jargon.)
(I tried eying through the OP but my eyes started bleeding from all the corporate IT jargon.)
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
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
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]
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.
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.
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.
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.
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.