| |
| ▲ | indolering 7 hours ago | parent [-] | | You haven't been a web developer since you posted that article either, since you won't retract silly arguments on your website: "Government Controlled PKI!" - Governments own the domains, you just rent them. They can kick your site off and validate their HTTPS certs regardless of DNSSEC. "Weak Crypto!" - 1K key sizes were fine given the threat model required cracking one in a year. They have since been increased. "DNSSEC Doesn’t Protect Against MITM Attacks" - DNSSEC protects against MITM attacks! - It's just that most clients don't perform local validation due to low adoption. - In reality, you are just making the circular argument to NOT adopt DNSSEC because adoption is low. - There are LOTS more MITM opportunities with HTTPS. We spent a massive effort on cert transparency, yet even Cloudflare missed a rouge cert being issued. "There are Better Alternatives to DNSSEC" - There is no alternative to signing domain name data and you point to crypto systems that do something other than that. - "There are better alternatives to HTTPS: E2E JS crypto with trust on first use" - What about SSH? I guess we are doomed to run everything over HTTPS and pay dumb cert authorities for the privilege of doing so. "Bloats record sizes" - ECC sigs can be sent in a single packet. - Caching makes first connect latency irrelevant. On and on and on. These are trivially refutable but you just shut the conversation down and point out instances of downtime ... as if DNS doesn't cause a lot of downtime anyaway. | | |
| ▲ | some_furry 7 hours ago | parent | next [-] | | > "Bloats record sizes" > - ECC sigs can be sent in a single packet. It's 2026. If you're deploying a cryptosystem and not considering post-quantum in your analysis, you'd best have a damn good reason. ECC signs might be small, but the world will be moving to ML-DSA-44 in the near future. That needs to be in your calculus. | | |
| ▲ | indolering 7 hours ago | parent [-] | | True, but DNSSEC doesn't need to worry about forward secrecy and it doesn't need quantum protection until someone can start breaking keys in under a year. Hopefully we will find more efficient PQC by then. | | |
| ▲ | tptacek 7 hours ago | parent [-] | | People tried to move DNSSEC from RSA to ECC more than a decade ago. How'd that migration go? If you like, I can give you APNIC's answer. | | |
| ▲ | indolering 6 hours ago | parent [-] | | RSA is still fine given that you can't break it in a year and we aren't worried about forward secrecy. Also, I worked for a DNS company. People stopped caring about ulta-low latency first connect times back in the 90s. You are clearly very proud of your work devaluing DNSSEC. But pointing to lack of adoption doesn't make your arguments valid. | | |
| ▲ | ekr____ 6 hours ago | parent | next [-] | | > People stopped caring about ulta-low latency first connect times back in the 90s. They did? That's certainly going to be news to the people at Google, Mozilla, Cloudflare, etc. who put enormous amounts of effort into building 0-RTT into TLS 1.3 and QUIC. | | |
| ▲ | indolering 6 hours ago | parent [-] | | I did a large data analysis of DNS caching times across the web. Hyperscalers are the only ones who care and they fix that with insanely long DNS caching. | | |
| ▲ | ekr____ 6 hours ago | parent [-] | | I'm not trying to just nitpick you here, but, the message I was responding to said "People stopped caring about ulta-low latency first connect times back in the 90s.". It seems to me that you're saying here that (1) the hyperscalers do care but (2) it's under control. I'm not necessarily arguing with (2) but as far as the hyperscalers go: (1) they drive a lot of traffic on their own (2) in many cases they care so their users don't have to. | | |
| ▲ | indolering 5 hours ago | parent [-] | | Sorry, the point I was trying to make is that this isn't a problem operationally. Hyperscalers go to crazy lengths because they can measure monetary losses due to milliseconds of less view time and it's much easier when they have distributed cloud infrastructure anyway. But it's not really solving a problem for their customers. At least when I worked in DNS land ... latency micro-benchmarking was something of a joke. Like, sure, you can shave off a few tens of milliseconds, but it's super expensive. If you want to reduce latency, just up your TTL times and/or enable pre-fetching. As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. DoH also introduces latency, yet people aren't worried about that being a deal killer. | | |
| ▲ | ekr____ 4 hours ago | parent [-] | | > As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. So I'm not sure this is as strong an argument as you seem to think it is. > DoH also introduces latency, yet people aren't worried about that being a deal killer. Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH.
https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-... And here are some measurements from Hounsel et al. https://arxiv.org/abs/1907.08089 | | |
| ▲ | indolering 4 hours ago | parent [-] | | > They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. But if it's worth doing for HTTP, why not for DNS? > Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH. Oh fun! | | |
| ▲ | ekr____ 4 hours ago | parent [-] | | > But if it's worth doing for HTTP, why not for DNS? I'm sorry I don't understand your question. | | |
| ▲ | indolering 3 hours ago | parent [-] | | The engineering effort! ECC solves the theoretical concerns around latency anyway yet we have people arguing that it shouldn't be done. But if it was worth making HTTPS faster to secure HTTP, why not DNS? | | |
| ▲ | ekr____ 3 hours ago | parent | next [-] | | Ah, I see what you're asking. You're not going to find this answer satisfying, I suspect, but there are two main reasons browsers and big sites (that's what we're talking about) didn't bother to try to make DNSSEC faster: 1. They didn't think that DNSSEC did much in terms of security. I recognize you don't agree with this, but I'm just telling you what the thinking was.
2. Because there is substantial deployment of middleboxes which break DNSSEC, DNSSEC hard-fail by default is infeasible. As a consequence, the easiest thing to do was just ignore DNSSEC. You'll notice that they did think that encrypting DNS requests was important, as was protecting them from the local network, and so they put effort into DoH, which also had the benefit of being something you could do quickly and unilaterally. | |
| ▲ | akerl_ 3 hours ago | parent | prev [-] | | HTTPS solved a bunch of real world threat models that were causing massive security issues. So we collectively put a bunch of engineering time into making it performant so that we could deploy it everywhere with minimal impact on UX and performance. | | |
| ▲ | indolering 2 hours ago | parent [-] | | DNSSEC also solves a bunch of real world threat models that do cause massive security issues. I think we should put that effort into DNS as well. | | |
| ▲ | tptacek 2 hours ago | parent | next [-] | | Somehow they cause these massive security issues without impacting the 95%+ of sites that haven't used the protocol since it became viable to adopt a decade and a half ago. It's just a very difficult statistic to get around! Whenever you make a claim like this, you're going to have address the fact that basically ~every high-security organization on the Internet has chosen not to adopt the protocol, and there are basically zero stories about how this has bit any of them. | |
| ▲ | akerl_ 2 hours ago | parent | prev [-] | | Does it? I run a bunch of websites personally. I have ACME-issued TLS certificates from LetsEncrypt. I monitor the Certificate Transparency logs, and have CAA records set. What's the threat model that should worry me, where DNSSEC is the right improvement? |
|
|
|
|
|
|
|
|
|
| |
| ▲ | tptacek 6 hours ago | parent | prev [-] | | I don't know about "valid". "Correct", maybe? "Prescient"? |
|
|
|
| |
| ▲ | thunderfork 6 hours ago | parent | prev | next [-] | | >It's just that most clients don't perform local validation due to low adoption. From your link elsewhere, https://easydns.com/blog/2015/08/06/for-dnssec/ >We might see a day when HTTPS key pinning and the preload list is implemented across all major browsers, but we will never see these protections applied in a uniform fashion across all major runtime environments (Node.js, Java, .NET, etc.)[...] Is this not the same flaw? | | |
| ▲ | ekr____ 6 hours ago | parent | next [-] | | It's actually not safe for clients to perform local validation because a quite significant fraction of middleboxes and the like strip out RRSIG and the like or otherwise tamper with the records in such a way that the signatures don't validate. | |
| ▲ | indolering 6 hours ago | parent | prev [-] | | No! Because it's totally possible for operating system vendors to flip that switch without requiring every upstream project to adopt key pinning. It's MUCH less infrastructure to upgrade. |
| |
| ▲ | tptacek 7 hours ago | parent | prev [-] | | Sir, this is a Wendy's. | | |
| ▲ | indolering 6 hours ago | parent [-] | | You claim in a sibling comment that you have engaged with my points, yet when I talk to you about it you just shut down the conversation. You really aren't going to respond to any of those points? You stand by your complaint DNSSEC being "government controlled PKI" when TLDs are a government controlled naming system? And your alternative is to advocate for privately owned PKI run by companies with no accountability that are also much more vulnerable to attack? Campaigning against cryptographically signing DNS records is a weird life choice man. | | |
| ▲ | tptacek 6 hours ago | parent [-] | | You're on tilt. It's fine that we disagree about DNSSEC. You seem very angry that you? (it was you, I gather?) wrote a post disagreeing with my post, and I didn't go back and revise my post to capture all the arguments you had that I disagreed with. Sorry, but not sorry. This is just crudding up the thread now though. If I've said something in this thread that you disagree with, say so and say why (you'll need something better than "I wrote about this 11 years ago and you weren't nice enough to me about it"). Right now, all you're doing is yelling about a post I wrote 11 years ago and haven't cited once on this thread. Of course, as you know, I stand by that post. But it's not germane to the thread. | | |
| ▲ | indolering 6 hours ago | parent [-] | | > You're on tilt. I'm upset that your incorrect arguments have gotten so much traction that the internet is a less safe place for it. > wrote a post disagreeing with my post, and I didn't go back and revise my post to capture all the arguments you had that I disagreed with. Sorry, but not sorry. You in a sibling thread: > I feel pretty confident that the search bar refutes this claim you're making. What you're trying to argue is that I've avoided opportunities to argue about DNSSEC on HN. Seems... unlikely. It seemed like you wanted to have this discussion but I guess not. > yelling about a post I wrote 11 years ago and haven't cited once on this thread. ... Of course, as you know, I stand by that post. But it's not germane to the thread. Do you know what comment thread you are in? I complained about FUD and cited your blogpost. This is what this thread is about. | | |
| ▲ | tptacek 6 hours ago | parent [-] | | Have you considered that telling me how influential my writing on this topic has been is not a great way to get me to stop writing? | | |
| ▲ | indolering 6 hours ago | parent [-] | | [flagged] | | |
| ▲ | tptacek 6 hours ago | parent [-] | | It's OK. I'm working on another post right now, titled "Stick A Fork In It", and you can write a rebuttal, "Pull The Fork Out Of It" and we'll get another chance to do this. We'll see who's more influential. ;) I'm tickled a the idea that I get to take credit for its demise, though I don't think that's entirely fair. Either way: we're witnessing its agonal breathing. This is an easy call. | | |
| ▲ | indolering 6 hours ago | parent [-] | | [flagged] | | |
| ▲ | tptacek 6 hours ago | parent [-] | | I'm not kidding. I've been meaning to write the post for a long time, but some stuff is about to happen to make the prediction clearer. I'm not just talking about the new post to mess with you (I don't know who you are). | | |
| ▲ | indolering 6 hours ago | parent [-] | | Then why the trolling? You claim to be interested in engaging in a substantive conversation or having done so in the past but when I try, you just insult me and announce that my advocacy for DNSSEC has inspired you to go hate on it more. | | |
| ▲ | tptacek 5 hours ago | parent [-] | | I think you are confusing me not believing you have a single plausible argument with me trolling you. I promise, when I write stuff about DNSSEC, I'm not thinking about you at all. I learned 10 minutes ago that you were the author of this post you're so wound up about! | | |
| ▲ | indolering 5 hours ago | parent [-] | | > Sir, this is a Wendy's. This you? | | |
| ▲ | tptacek 4 hours ago | parent [-] | | Yes, that's a colloquialism meaning "none of this stuff you just wrote has anything to do with the discussion we're actually having". You gave a long point-by-point rebuttal to a post that is not part of the thread. I'm not interested in debating that post with you right now. If it shows up on the front page of HN again, then I'll be happy to go through it with you. Feel free to submit it. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
