> 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.
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.