There are a whole plethora of practical reasons why DANE turned out to be unworkable, but this really is the core of it. It's worth keeping in mind that you can revoke an entire CA --- immensely popular and important CAs have been entirely removed from trust stores, quite recently --- but you can't do that with the DNS hierarchy. You can't do long term secrets without some form of revocation, and that's fundamentally what DANE represents.
> It's worth keeping in mind that you can revoke an entire CA
> ... but you can't do that with the DNS hierarchy.
DANE effectively revokes ALL CAs. Forever.
Once again, you are confused about what is the role of TLDs in DANE. They are not equivalent to CAs in WebPKI.
In a DANE-based PKI system, TLDs have neither less nor more power than they already have today with the WebPKI system.
So there is exactly as much need to revoke them in DANE as there is today with the WebPKI system, which is also susceptible to the exact same attacks from TLDs as the DANE-based PKI system.
> It's worth keeping in mind that you can revoke an entire CA --- immensely popular and important CAs have been entirely removed from trust stores, quite recently
You can, but browser vendors are reluctant to do it because it would break, potentially, thousands or millions of websites if a single CA gets removed from trust stores.
And it would take months or years for that removal to be reflected in millions of deployed systems out there who seldom or never update.
Are you saying registrars are equivalent to CAs now and they can revoke domains just like they could reclaim them before? Right now, I trust TLDs to tell me the NS of the domain so I can query its IP against that NS, I don't trust them to validate that the true owner of the site currently controls the domain. So under DANE, who else if not TLDs does one ultimately trust to attest to that claim? Honestly asking, I don't know enough about DANE.
> Are you saying registrars are equivalent to CAs now and they can revoke domains just like they could reclaim them before?
I'm sorry, I don't understand the question. Could you rephrase it or expand on it? Specifically, I don't understand what "before" is in regards to -- before what?
> Right now, I trust TLDs to tell me the NS of the domain so I can query its IP against that NS, I don't trust them to validate that the true owner of the site currently controls the domain.
But you trust registrars for that, right? And registrars basically send that information to the TLD and coordinate with the TLD so that they point the NS record to whatever the owner of the domain wants.
Either way, yes, both your registrar and your TLD have the same technical ability to attack and perform a man-in-the-middle against your entire domain, either in the current WebPKI system or a DANE-based PKI system. So that is not a problem with DANE any more than it's a problem with the WebPKI system.
Of course, what is possible to do technically and what is legal can be entirely different matters. But it is technically possible, and usually illegal in most circumstances (except under judicial order or as a result of law enforcement I suppose), to do these kinds of attacks with both DANE and WebPKI.
> So under DANE, who else if not TLDs does one ultimately trust to attest to that claim? Honestly asking, I don't know enough about DANE.
Which claim, who is the owner of the site? It would be the same as it is now. As far as I understand, registrars do that and then coordinate with whoever manages the TLD.
In fact, that's what I've been saying, the criticism against DANE is equally valid with WebPKI, because the domain system would be the same. Except WebPKI is more fragile and has a lot more weak links in its chain.
tptacek says you can't revoke keys in a DANE system. Yes, you can, you can revoke them yourself! You don't need to wait for browser vendors to revoke an entire CA, potentially affecting thousands or millions of other websites. And they may actually decide not to revoke the CA, even if they issued rogue certificates, for several reasons.
What browsers can't do in DANE is revoke the TLD's keys (but the TLDs can do it themselves if they were attacked). But of course, it makes no sense to revoke the TLD's keys if they are the attacker.
Because if a TLD hijacks your domain (and they already do that today, whenever law enforcement and judges require them to do it), then neither DANE nor WebPKI can do squat about it.
DANE doesn't revoke any CAs. You can read AGL's post about why DANE just adds an nth new CA to the trust store (or, it would: no browser currently plans to adopt DANE; browsers actually removed their DANE code).
Meanwhile: it simply is the case that if LetsEncrypt starts misissuing certificates, Google and Mozilla can (and likely will) revoke it. Meanwhile: if the operators of the root zone or any the FVEY TLDs misissue, nobody can revoke them.
You could try to argue that this was academic, except that the USG routinely and publicly manipulates the DNS for policy reasons.
> 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.
Respectfully, 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.
> 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!).
OK, I hadn't read that post before. Some of the arguments you had already made but some I hadn't read before.
But I mean, it doesn't bode well when even the first paragraph is incorrect:
> All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Securing those DNS lookups therefore enables no meaningful security.
This is incorrect because if an attacker can make a DNS lookup (say for example.com) resolve to an attacker-controlled entry (and there are multiple ways to do this), the attacker can trick almost all CAs into signing a certificate for example.com, which the attacker can use to perform a MITM attack against example.com.
So WebPKI fails to protect against insecure DNS.
> DNSSEC is a Government-Controlled PKI
This is the same "moving the goal posts" argument. The government already controls the domain system, so you wouldn't be any worse with DNSSEC and DANE than with insecure DNS and WebPKI. You'd actually be much more secure.
I mean, sure, if you want to propose a security system that has all the benefits of DNSSEC and also subverts the government, feel free to do so (and good luck with that).
> In a world where users rely on DANE, those governments have much of the same cryptographic authority as the CAs do now
Governments would have the same authority as today. Nothing would change with that. I'm not sure why you think DNSSEC has to subvert the government when neither insecure DNS nor WebPKI does that.
In fact, insecure DNS and WebPKI allow a lot more attacks from governments, as any government can attack any website in the entire world.
> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
Muammar Gaddafi could have controlled BIT.LY's TLS keys with the WebPKI system, if he wanted!
Or do you think insecure DNS and the WebPKI system protects against a government hijacking a domain? It doesn't, at all! Governments routinely hijack/seize (and block) domains with the current system.
> DNSSEC is Cryptographically Weak
> A modern PKI would almost certainly be based on modern elliptic curve signature schemes,
As far as I know DNSSEC supports elliptic curves.
> But the code that handles lookups today is buried deep in the lowest levels of application network code, and is rarely if ever wired for user interface.
Browsers can definitely have such a UI, they already have their own DNS caching mechanisms and whatnot. And other applications already have the same problem with TLS, this is no different with DNSSEC.
> DNSSEC is harder to deploy than TLS.
Yeah, I'm not sure about that. Like you said before, DNSSEC was automatically enabled by registrars in Europe for millions of customers, without them doing anything.
And even when it's not automatically enabled, usually you just have to tick a box in your DNS provider and/or copy a key into your registrar.
Sure, more complicated deployments are possible but the same is true for TLS.
In fact, even the most basic TLS deployment requires significantly more steps than enabling DNSSEC.
> In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.
It does if the last mile is DNS-over-HTTPS, or DNS-over-TLS, or the client does DNSSEC validation.
> Even if DNSSEC was deployed universally and every zone on the Internet was signed, a coffee-shop attacker would still be able to use DNS to man-in-the-middle browsers.
No, nowadays this wouldn't be a realistic scenario anymore.
Clients should do DNS-over-HTTPS and/or DNS-over-TLS and/or DNSSEC validation.
> DNSSEC is Unsafe
It's not, you mentioned NSEC3 yourself below, while dismissing it as "bizarro", which I don't see how it can be a valid argument.
> DNSSEC is Architecturally Unsound
> effective security is almost invariably application-level and receives no real support from the network itself.
Right, because applications do so much to enforce DNS security and handle DNS hijacks nowadays.
If DNSSEC was enabled by default then applications wouldn't have to worry about DNS security and they would be just fine.
But those that wanted it, could still handle it differently (like browsers). For example, by having a DANE version of openssl which would give them more information about failures.
> How could US government IT not love it?
Oh, why don't you ask that about the WebPKI? That's a government's dream come true, actually.
With WebPKI, countries like Russia / China / Ethiopia / Somalia / Whatever can perform MITM attacks on .COM domains. Or whatever TLD they want.
With DNSSEC and DANE they can't.
> If you’re running systems carefully today, no security problem you have gets solved by deploying DNSSEC.
Yes, because everyone is running systems so carefully today.
And if no security problem gets solved by deploying DNSSEC, will you let me MITM your DNS server and we'll see what happens?
Haven't CAs already demonstrated their incompetence, power abuse and inability to prevent governments from around the world from attacking domains in other countries?
I really mean no offense or disrespect, but this post honestly just reads like a bunch of FUD to me...
> This is incorrect because if an attacker can make a DNS lookup (say for example.com) resolve to an attacker-controlled entry (and there are multiple ways to do this),
That'd be annoying to achieve, unless the authoritative name server is compromised... oops.
> This is the same "moving the goal posts" argument. The government already controls the domain system, so you wouldn't be any worse with DNSSEC and DANE than with insecure DNS and WebPKI. You'd actually be much more secure.
Compromising both nameserver operators and public CA's is much more difficult and much more visible. There is *no transparency* with DNSSEC alone.
> Yeah, I'm not sure about that.
DNSSEC deployment percentage by TLD should confirm it for you. If it's not that hard, why do some ccTLD's still not support it? It's ridiculous that website owners' website security should depend on that.
> It does if the last mile is DNS-over-HTTPS, or DNS-over-TLS, or the client does DNSSEC validation.
DNS-over-DANE-HTTPS sounds a bit tautological, doesn't it?
> In fact, even the most basic TLS deployment requires significantly more steps than enabling DNSSEC.
It really doesn't if we're speaking of DANE vs. WebPKI.
> It's not, you mentioned NSEC3 yourself below, while dismissing it as "bizarro", which I don't see how it can be a valid argument.
NSEC3 which is considered barely a hindrance to zone walking.
> If DNSSEC was enabled by default then applications wouldn't have to worry about DNS security and they would be just fine.
Assuming operators enable it
> Oh, why don't you ask that about the WebPKI? That's a government's dream come true, actually.
And DNSSEC would be even more so.
> With DNSSEC and DANE they can't.
Ehh? That's a leap.
> Yes, because everyone is running systems so carefully today.
And they'll be more diligent with DNSSEC which has far fewer safeguards?
> Haven't CAs already demonstrated their incompetence, power abuse and inability to prevent governments from around the world from attacking domains in other countries?
And haven't registrars demonstrated the same? Oh, that's right, we wouldn't know, because there's no oversight, there's barely any deployment, there's barely any good tooling.
> I really mean no offense or disrespect, but this post honestly just reads like a bunch of FUD to me...
I'd really say the same about claiming DNSSEC+DANE would "fix" WebPKI.
> That'd be annoying to achieve, unless the authoritative name server is compromised... oops.
We weren't discussing how annoying it is to achieve, just whether WebPKI protects against insecure DNS or not. And it doesn't (in some scenarios), because it depends on DNS to generate valid certificates but has no way to validate DNS responses (which could have been compromised in transit, by multiple kinds of attacks).
> Compromising both nameserver operators and public CA's is much more difficult and much more visible. There is no transparency with DNSSEC alone.
How is it much more difficult? It's exactly as difficult as compromising nameserver operators in DANE. If you compromise the nameserver then the CA would be automatically compromised as well.
There is no transparency with WebPKI either unless the target is a website, not any other kind of TLS-based service.
Either way, tptacek and I have already discussed in another post how a DANE-based transparency scheme would work and it would be much easier and less resource intensive to do than certificate transparency.
> DNSSEC deployment percentage by TLD should confirm it for you. If it's not that hard, why do some ccTLD's still not support it? It's ridiculous that website owners' website security should depend on that.
Because there's not much value in doing so yet. The vast majority of clients aren't validating DNSSEC by default yet.
> DNS-over-DANE-HTTPS sounds a bit tautological, doesn't it?
I don't see a problem, although some special code might have to be written to handle that. You'd just need to validate the certificate of the DNS server before declaring the DNS-over-HTTPS connection as authenticated. The DNS server could provide the signed responses upon establishing the TCP connection, which the client would validate.
> And DNSSEC would be even more so.
No, it would be less so. Have you even read any of my arguments?
As I said, governments can attack any TLS-based service in the world right now.
With DNSSEC and DANE, they couldn't -- they could only attack domains over which they already have control.
> Ehh? That's a leap.
Please explain how so.
Explain how they would be able to do a MITM attack if they have no control over an unrelated TLD, which would be needed to sign a valid certificate.
> And haven't registrars demonstrated the same? Oh, that's right, we wouldn't know, because there's no oversight, there's barely any deployment, there's barely any good tooling.
Right, there isn't, which is why we should change that.
> I'd really say the same about claiming DNSSEC+DANE would "fix" WebPKI.
I didn't claim that, so your statement is invalid.
I only claimed that DNSSEC+DANE is simpler and much more secure than insecure DNS+WebPKI. Which makes it worth to transition to.
The two systems would need to coexist during the transition period, but for any already-transitioned domain, the benefits would be clear and substantial.
Arguments about slow adoption are invalid because almost no effort (DNS-over-HTTPS being the exception) is currently being made by those who actually have the means to drive adoption (i.e. Mozilla, Google, Apple, Microsoft).
> We weren't discussing how annoying it is to achieve, just whether WebPKI completely protects against insecure DNS or not. And it doesn't.
Security of trust services basically always boil down to how "annoying" they are to compromise.
> How is it much more difficult? It's exactly as difficult as compromising nameserver operators in DANE.
Because there's actual oversight of the compliance and oversight of WebPKI CAs, unlike DNSSEC.
> Either way, tptacek and I have already discussed in another post how a DANE-based transparency scheme would work and it would be much easier and less resource intensive to do than certificate transparency.
No standard, no proof.
> Because there's not much value in doing so yet. The vast majority of clients aren't validating DNSSEC by default yet.
Because it's more difficult than TLS, while not being better than it.
> With DNSSEC and DANE, they couldn't -- they could only attack domains over which they already have control.
Says you?
> No, it would be less so. Have you even read any of my arguments?
You haven't provided arguments why that would be the case.
> Please explain how so.
Please explain how so. I shouldn't be trying to prove the negative of your initial claim that is without support.
> I only claimed that DNSSEC+DANE is simpler and much more secure than insecure DNS+WebPKI.
> Security of trust services basically always boil down to how "annoying" they are to compromise.
No, real security is achieved by mathematical / cryptographic impossibility. "Annoyance" is hardly a deterrent, except for the least determined attackers.
> Because there's actual oversight of the compliance and oversight of WebPKI CAs, unlike DNSSEC.
That doesn't matter at all, because if you compromise the domain's nameserver (like you would have to do in DANE to attack it), then CAs will just happily sign a rogue certificate, which can be used to do a MITM.
> No standard, no proof.
What a good argument. Your argument is basically like saying in 2002: "electric vehicles aren't viable because no infrastructure for them exists right now".
> Says you?
Well, if I'm wrong why don't you tell me why I'm wrong? How is that an argument?
> You haven't provided arguments why that would be the case.
I have, please read my comments.
I will say it again briefly so you can understand it: governments currently can attack any domain in the world, regardless of TLD.
In DNSSEC+DANE they could only attack their own TLDs.
Insecure DNS and WebPKI is therefore a government's dream come true, not DNSSEC+DANE.
> Please explain how so. I shouldn't be trying to prove the negative of your initial claim that is without support.
In DNSSEC+DANE governments can't compromise CAs, because they wouldn't exist.
That's why DNSSEC+DANE prevents the governments of Russia and China from doing MITM attacks against TLS-based services in .COM domains.
Do you understand now?
> > I only claimed that DNSSEC+DANE is simpler and much more secure than insecure DNS+WebPKI.
> And that's the FUD part.
Well, if you think it's FUD, are you going to actually provide valid technical arguments about why it's FUD like what I did with tptacek's post, or are you just going to nitpick my arguments, completely miss the points I was making and then accuse me of FUD?
> No, real security is achieved by mathematical / cryptographic impossibility.
You can't do trust that way. It's an entirely human concept for which we use cryptography for it to scale better.
> That doesn't matter at all
Says you? Again. You're ignoring half of the rationale behind CT (which I will *not* be rephrasing here, it's freely available to read).
> What a good argument.
It is. Unless you can actually show a working DNSSEC transparency standard, it doesn't exist. Some hypothetical future feature to remedy flaws is *really* not a strong argument towards DNSSEC.
> Well, if I'm wrong why don't you tell me why I'm wrong? How is that an argument?
There's no argument, just your opinion. It's starting to become funny how vague this discussion is becoming with you avoiding providing anything of substance that could be properly refuted.
> In DNSSEC+DANE they could only attack their own TLDs.
Huh? They'd attack any of the myriad of registries, just like they could attack CA's. It's just that CA's are held to a much higher standard and supervision. You can't just ignore that part.
> In DNSSEC+DANE governments can't compromise CAs, because they wouldn't exist.
This is just nominative pedantry, they're functionally still trust authorities that can be compromised. Call them CAs or Key-As, it doesn't matter.
> Well, if you think it's FUD, are you going to actually provide valid technical arguments about why it's FUD
It's very asymmetric effort for me to counter non-technical opinions and hypotheticals with technical ones. Not very fair towards my time and I'm not going to.
> completely miss the points I was making and then accuse me of FUD?
You're the one calling it "insecure WebPKI" while dismissing everything wrong with DNSSEC, so it's not even an accusation, it's an astute observation.
