You know that sinking feeling when you realize your company’s security is still running on Windows XP? Well, the internet has the same problem — and it’s way worse. This week, the IETF published RFC 10015, a formal document that deprecates obsolete key exchange methods in TLS 1.2 and DTLS 1.2. Sounds like a boring technical fix, right? Wrong. It’s a confession.
Let me translate: We are still writing rules to outlaw cryptographic methods that were already considered weak in 2018. We are patching a protocol that was superseded by a far superior version — TLS 1.3 — years ago. And we’re doing it because the alternative (actually upgrading) is too hard for the people who run the internet’s most critical infrastructure.
We are not building the future. We are endlessly patching the past. That’s the uncomfortable truth that RFC 10015 screams from every page.
The top comment on the RFC announcement says it all: “Couldn’t folks just use TLS 1.3?” Yes. Yes, they could. TLS 1.3 is faster, more secure, and eliminates entire classes of vulnerabilities. But it requires changes to legacy systems — banks, government portals, factory floors, embedded devices — that are running on code written before the iPhone existed. So instead of upgrading, the industry spends another decade writing RFCs to police the old version.
This is the internet’s dirty secret: our security is held hostage by the slowest adopter. One enterprise with a 20-year-old payment gateway can force the entire ecosystem to keep supporting attacks from 1998. The IETF is not a standards body anymore; it’s a janitorial service for technical debt.
I’ve seen this firsthand. A Fortune 500 bank I worked with still uses RSA key exchange with 1024-bit keys — deprecated in 2014. Their excuse? “The hardware is certified and we can’t touch it.” So the rest of us have to keep defending against Logjam and DROWN attacks because someone’s compliance paperwork is more important than actual security.
Publishing a new RFC to deprecate old methods in an already-obsolete protocol is not a victory. It’s a white flag.
Here’s the twist: this RFC is actually a sign of failure. Not failure of the protocol designers — they made TLS 1.3 a decade ago. Failure of the industry to prioritize migration over maintenance. We spent billions on AI this year, but we can’t find the budget to update a TLS library? The math doesn’t add up.
What this means for you: If you’re still running TLS 1.2, you’re not just behind — you’re actively making the internet less secure for everyone. And if you think using TLS 1.3 makes you safe, think again. The same pattern will repeat with QUIC, with DNSSEC, with every future protocol. Better technology doesn’t win. The least painful upgrade path wins.
So the next time you see an RFC deprecating something old, don’t nod and move on. Ask yourself: why is this still needed? The answer is always the same — because we failed to migrate. And that’s the real security problem we should be talking about.
FAQ
Q: Why not just force everyone to use TLS 1.3?
A: Because forcing requires breaking compatibility with millions of legacy devices and systems that can't be upgraded. The internet's decentralized nature means no one can mandate a switch — only encourage and deprecate the old. That's why we get RFCs like this instead of real change.
Q: What does this mean for my organization?
A: If you're still using TLS 1.2, you are now actively maintaining a protocol that the IETF is explicitly marking as insecure. Start planning your migration to TLS 1.3 immediately. If you're already on 1.3, you're ahead — but this pattern will repeat. Build a culture of continuous upgrade, not patch-and-hope.
Q: Isn't this just standard protocol maintenance?
A: That's the polite way to say it. The cynical truth is that this RFC is a symptom of a broken upgrade culture. We should have been fully on TLS 1.3 by 2020. Instead, we're writing rules to ban attacks from 2015. It's maintenance, yes — but it's maintenance that should have been unnecessary.