3 ms·

> 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

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

Avamander 4y ago
> 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. And that's the FUD part.
- wizeman 4y ago
  > 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?

Avamander 4y ago

> 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. And that's the FUD part.

wizeman 4y ago
> 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?