4 ms·
> You can read AGL's post about why DANE just adds an nth new CA to the trust store Who's AGL and where is that post? I don't see why it would be like adding
by wizeman 4y ago
> You can read AGL's post about why DANE just adds an nth new CA to the trust store
Who's AGL and where is that post?
I don't see why it would be like adding a new CA. If the client can do DNSSEC validation then he could just use DANE, bypass the whole WebPKI system and basically distrust all CAs (if the website has already migrated to DANE).
It's not the same as adding a new CA, because in that case you are trusting that CA and you are also trusting all other CAs at the same time.
> (or, it would: no browser currently plans to adopt DANE; browsers actually removed their DANE code).
Yeah, I wonder why they did that. So Firefox adds DNS-over-HTTPS but then it doesn't implement DANE?
How does that make any sense? If you're already doing DNS-over-HTTPS then you're basically already at the point where you can get full DANE protection for free.
> Meanwhile: it simply is the case that if LetsEncrypt starts misissuing certificates, Google and Mozilla can (and likely will) revoke it.
According to their own stats, Let's Encrypt is protecting around 300 million active domains.
Which means Google and Mozilla can't revoke Let's Encrypt without breaking the Internet. So don't count on that happening, ever.
> Meanwhile: if the operators of the root zone or any the FVEY TLDs misissue, nobody can revoke them.
If those operators were attacked, they can revoke themselves.
If they are the attacker (like when the government hijacks your website due to e.g. piracy), you are exactly as screwed as you would be with the WebPKI system.
> You could try to argue that this was academic, except that the USG routinely and publicly manipulates the DNS for policy reasons.
Yes. And how does the WebPKI secure your website when that happens? Answer: it doesn't.
You're moving the goal posts and you don't even notice.
- tptacek 4y agoRespectfully, it sounds like you haven't paid much attention to the last 10 years of browser DNSSEC integration. For instance: you seem shocked (disbelieving, maybe?) at the idea that browsers can't simply enable end-to-end DANE validation. Here's a thing: DNSSEC records don't even universally transit the Internet; very widely deployed middleboxes will block DNS packets that contain DNSSEC signatures or DANE records. There's no point in arguing this stuff, because we're operating from different premises. You read about DANE and think it's great. I know the feeling! I was a huge HPKP booster back in the day; that didn't work either. Meanwhile, one of my premises is: we can only do things that actually work, not just things we wish would work. (I happen to not wish for a single Internet-wide government-controlled top-down PKI rooted in 1990s cryptography, but that's not relevant to my argument.) I understand if you feel like I'm moving the goalposts. You don't know where the goalposts are. That's OK. But I assure you: there is no need for me to move them at all; my argument just isn't far enough from the end zone to bother.
- wizeman 4y ago> Respectfully, it sounds like you haven't paid much attention to the last 10 years of browser DNSSEC integration. You are correct. That could mean I'm wrong, but it doesn't necessarily mean so. I would be happy to know whether I'm wrong and why. > For instance: you seem shocked (disbelieving, maybe?) at the idea that browsers can't simply enable end-to-end DANE validation. Here's a thing: DNSSEC records don't even universally transit the Internet; very widely deployed middleboxes will block DNS packets that contain DNSSEC signatures or DANE records. Indeed. That is solved by DNS-over-HTTPS for which Firefox and Android already have an implementation. > There's no point in arguing this stuff, because we're operating from different premises. You read about DANE and think it's great. I know the feeling! I was a huge HPKP booster back in the day; that didn't work either. Meanwhile, one of my premises is: we can only do things that actually work, not just things we wish would work. Sure, if it wouldn't work I would accept it (although I'd like to know why). But you haven't given me a convincing argument about why it can't work. As far as I can see, in other posts you're just arguing about things DANE should solve that WebPKI doesn't. And in this post, you're just taking into account how things stand at the present and not taking into consideration what organizations like Mozilla, Google, Apple and Microsoft could do to improve the situation, which let's be clear, is absolutely unacceptable in terms of security considering we are living in the year 2022. > I understand if you feel like I'm moving the goalposts. You don't know where the goalposts are. That's OK. But I assure you: there is no need for me to move them at all; my argument just isn't far enough from the end zone to bother. Yes, I do. The goal post is having a more secure system than insecure DNS and WebPKI while also being much simpler. DNSSEC and DANE achieve that. But you say that it's preferable to have a worse, much more complex, much more insecure system just because governments can subvert DNSSEC and DANE (even though they can subvert WebPKI even more today!).
- tptacek 4y agoThe situation is far less "unacceptable" than you think it is, and DNSSEC would make things worse, not better. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/