Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNSSEC KSK rollover breaks DNS resolution for .nz domains

status.internetnz.nz

Post reply on HN
Print view View original

171–180 of 181 posts

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#171

Post by bawolff »

hsbauauvhabzb wrote: post #161
bawolff wrote: post #39

Earlier quoted context omitted.

> Dnssec also does not solve bgp hijacking This seems like a pretty unreasonable complaint. Dnssec also doesn't stop phishing. Or nukes.

What does dnssec solve then?

Authenticity of dns records. Making sure that the dns record points to the correct ip address.

Whether or not an ip address goes to the correct computer is totally unrelated to DNS, so i'm not sure why anyone would think that has anything to do with a dns security measure.

The relavant security thing for bgp is called rpki.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#172

Post by belorn »

tptacek wrote: post #166
belorn wrote: post #163

Earlier quoted context omitted.

If the attacker bgp hijacks the record target they need to also bgp hijack the authoritative server that holds the TLSA record (which the client could verify during an attack). If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server. If the attacker want to bgp hijack the TLD name servers they will need to bgp h…

None of this matters. An attacker who controls BGP controls IP routing. They can defeat ACME.

TLSA record can specify what specific hash the certificate must have (DANE-EE). You can't solve that with BGP and ACME. The certificate that you get from acme will have a different hash.

With CAA records you can also lock it down to a specific user and method (RFC 8657). How will you solve that with BGP using acme?

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#173

Post by belorn »

tptacek wrote: post #170
belorn wrote: post #164

Earlier quoted context omitted.

You said that registrars won't implement transparency logging, but certificate transparency was not created by certificate authoritative. Google added it to chrome, and they could just as easy add it to their own public resolver.

And then what happens? Google stops resolving .COM names? I don't think you've thought this through all the way.

"If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit" - tptacek

If Verisign knowingly missuses .com root certificate, Google could nuke them from orbit by making it public. That is the whole purpose of certificate logs. Verisign operate on trust and they are also certificate authority.

The damage to Verisign if they lost their status as certificate authority and as a trusted company would create so much fallout I am doubtful that ICANN and DNS would be left without major scars.

I don't think you've thought this through all the way.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#174

Post by teddyh »

acdha wrote: post #168
teddyh wrote: post #160

Earlier quoted context omitted.

That’s what a “CA” is . If someone is not in a browser’s CA list, they’re not a CA. So yes, you do trust all CAs.

That’s not all what CA means in standard usage. Terms like WebPKI exist specifically to make that distinction since, for example, the U.S. government runs its own certificate authorities which are trusted by millions of clients and even some mainstream software (Adobe) but not browsers. This is far from unique as far as governments go, and in some cases may even be required within a country.

Those non-web CAs are not the topic of discussion, though. When we are discussing the DNSSEC PKI, we are not discussing any altroots¹. When people are discussing the CA system for TLS, they overwhelmingly mean the normal web CAs.

1. https://en.wikipedia.org/wiki/Alternative_DNS_root

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#175

Post by agwa »

tptacek wrote: post #169
matthew9219 wrote: post #167

Earlier quoted context omitted.

You are looking for a debate, I think. It's the whole thread. You're nerd sniping. It's classic. You're not a fan of DNSSEC and prefer CT. When faced with examples where CT doesn't cut it, you refuse to discuss the big picture, pounce on incorrect details, and then resort to claiming your opponents are uninformed or arguing in bad faith. The bottom line is my original big picture claim, the part that's on-topic for t…

It is difficult to make any sense out of your claim that internet connected devices can't benefit from CT. The initial claim you made was based on the unreliable connectivity and update channels of those devices, neither of which are especially implicated in enforcing CT --- your belief was that devices went and checked CT logs over the Internet on the fly to validate certificates, which, of course, no. Ironically, t…

It's not a completely nonsensical concern - Chrome relies on a reliable connection to Google in order to get log list updates and do SCT auditing. If an attacker can block log list updates for long enough, CT enforcement is disabled entirely (i.e. certificates with no SCTs will be accepted), and if they can block SCT auditing for long enough, bogus SCTs will not be detected. This fail-open behavior was an intentional design choice so that CT would never break the Internet, as DNSSEC so often has. I think CT made very sensible tradeoffs here, but I understand matthew9219's complaints even if the details aren't entirely correct.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#176

Post by tptacek »

agwa wrote: post #175
tptacek wrote: post #169

Earlier quoted context omitted.

It is difficult to make any sense out of your claim that internet connected devices can't benefit from CT. The initial claim you made was based on the unreliable connectivity and update channels of those devices, neither of which are especially implicated in enforcing CT --- your belief was that devices went and checked CT logs over the Internet on the fly to validate certificates, which, of course, no. Ironically, t…

It's not a completely nonsensical concern - Chrome relies on a reliable connection to Google in order to get log list updates and do SCT auditing. If an attacker can block log list updates for long enough, CT enforcement is disabled entirely (i.e. certificates with no SCTs will be accepted), and if they can block SCT auditing for long enough, bogus SCTs will not be detected. This fail-open behavior was an intentional…

I'm hung up on the idea that challenges keeping a log list updated disqualify CT, thus motivating deployment of DNSSEC, a protocol so dependent on a clean connection to the Internet that its deployment in browsers on modern operating systems was derailed.

I acknowledge that embedded systems are a difficult place to do the policy-driven cryptographic security that we're talking about when we talk about the WebPKI and DANE. They're difficult for all sorts of reasons and they're difficult for all of software security, not just this. But they're pretty clearly also not a motivation for the deployment of DNSSEC; in fact, they're a sort of worst case for DNSSEC.

That's what this whole long subthread is about. It wasn't a strong argument. The thread has mostly been attempts to lay out why it isn't, without any interesting evidence for DNSSEC's suitability being presented.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#177

Post by tptacek »

teddyh wrote: post #174
acdha wrote: post #168

Earlier quoted context omitted.

That’s not all what CA means in standard usage. Terms like WebPKI exist specifically to make that distinction since, for example, the U.S. government runs its own certificate authorities which are trusted by millions of clients and even some mainstream software (Adobe) but not browsers. This is far from unique as far as governments go, and in some cases may even be required within a country.

Those non-web CAs are not the topic of discussion, though. When we are discussing the DNSSEC PKI, we are not discussing any altroots¹. When people are discussing the CA system for TLS, they overwhelmingly mean the normal web CAs. 1. https://en.wikipedia.org/wiki/Alternative_DNS_root

"The normal web CAs" means "the Mozilla and Chrome root programs". There are other CAs, and some of them are even in the root stores of other browsers, but they're not "trusted" in the sense you meant upthread.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#178

Post by tptacek »

belorn wrote: post #173
tptacek wrote: post #170

Earlier quoted context omitted.

And then what happens? Google stops resolving .COM names? I don't think you've thought this through all the way.

"If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit" - tptacek If Verisign knowingly missuses .com root certificate, Google could nuke them from orbit by making it public. That is the whole purpose of certificate logs. Verisign operate on trust and they are also certificate authority. The damage to Verisign if they lost their status as certificate authority and as a trusted comp…

That's not at all what "nuke from orbit" means. Google broke Thawte and Verisign. They didn't simply "make it public". Thank you for clarifying this; I could have been clearer. I think the distinction between what's possible in CT and DANE is much more obvious now.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#179

Post by matthew9219 »

nickf wrote: post #124
michaelt wrote: post #123

Earlier quoted context omitted.

If you are able to compromise a CA and generate a bogus certificate, why couldn't you also compromise a certificate transparency log provider and generate a bogus signed merkle hash? (Not that I'm a DNSSEC user myself, my feet aren't bulletproof)

Not sure what you really mean here - CAs are required to get SCTs from multiple, independently-operated logs. Even then, I think what you're implying here is mathematically impossible, and easily and immediately detectable. Bear in mind on at least 2 occasions these logs have detected and been decommissioned based on cosmic-ray induced bit-flips, not discovered by the actual log operators . CT is a pretty robust syst…

Fwiw (tangent), I don't necessarily believe either of those instances were cosmic-ray induced bit-flips. I'd have to dig up the study, but I read a study once that more or less concluded "cosmic-rays are more common in memory unsafe languages and on overclocked PCs". Or more accurately, engineers frequently misattribute memory corrupt and operating outside specification to cosmic rays.

Particularly when the software in question is running on somebody else computer, proprietary software and OS (or OS modules), unknown patch versions, etc.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#180

Post by yencabulator »

tialaramex wrote: post #116
theamk wrote: post #62

Earlier quoted context omitted.

The important stuff is not just websites I host, but also websites I visit. And in all the scenarios you mention, I (and everyone else) would know that it happened very clearly, as it is basically denial of service attack. Even if this is a takeover event with almost-instantaneous replacement with the phishing page, the website owner would detect this and if the website is at least a bit popular, the news would defin…

Web PKI CAs aren't psychic, they just use DNS. So your claim ends up being that you believe DNS answers from the DNS can be tampered with by parties who control those answers (which includes the TLD registrar, this part checks out), but, somehow every Web PKI CA would know if this happened and disregard the results. Not only is your claim obviously not true in principle, we know it's not true in practice, disrupted D…

DNSSEC can be tampered without leaving a trail of evidence. If you MitM DNS for all the outbound IPs a CA uses, the end result of that gets logged in Certificate Transparency. And since 1) sites can and do monitor CT for their domains and 2) browsers demand the certificate has been submitted to CT, we know that e.g. google.com is not MitM'ed.
Post reply on HN