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

141–150 of 181 posts

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

#141

Post by tptacek »

matthew9219 wrote: post #120
mjg59 wrote: post #117

Earlier quoted context omitted.

The Play Store has cert pinning, so this all works just fine in the scenario you're describing.

Web PKI so strong that we recommend not using it for critical scenarios.. /s It's late and I maybe haven't been super constructive here, but I think when you try to write out the actual assumptions behind CT as the whole solution, you realize you've got something that mostly works assuming assuming assuming - and worse, we'll never do any better, because those assumptions are fundamental technical limits. DNSSec may…

The whole premise of your argument about set-top boxes and CT was refuted, and you've used that as evidence that you were right all along.

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

#142

Post by tptacek »

agwa wrote: post #134
akerl_ wrote: post #132

Earlier quoted context omitted.

In addition to what nickf said in the parallel comment, CAs have committed to CT logging as part of being included in browser trust stores. If anyone were to find and report any certificates issued by those CAs via their trusted certificates that were not in CT logs, that would be strong evidence for browsers to remove them from the trust stores, which would essentially destroy their company.

That is not true. CAs are not required to log their certificates. Instead, Chrome and Safari by default do not accept certificates unless they are accompanied by a signed receipt from a recognized log. If you don't need your certificate to work in a default-configured Chrome or Safari there is no need for your certificate to be logged. Source: I work in this space

Here what you really mean is "if your certificates will never touch Chrome", because it's not just that Chrome won't accept them, but that Chrome's SCT auditing is part of a surveillance system for certificate misissuance.

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

#143

Post by tptacek »

belorn wrote: post #118
tptacek wrote: post #46

Earlier quoted context omitted.

People say this all the time, but of course the WebPKI has Certificate Transparency, requiring every issuer to register every certificate issued in a globally monitored tamper-proof log, and DNSSEC doesn't. Moreover, the WebPKI got CT because the browser root programs were able to force the CAs to join it. They have no such influence over DNS registrars, many of which are de jure controlled by world governments and w…

If the issue is the lack of certificate transparency, then add that as a new standard to dnssec. Certificate Transparency came into the picture around 2013, by which time https was fairly old. Public resolvers like google, quad 9, and cloudflare could create Certificate Transparency for dnssec today if there was a demand for it.

I've explained several times on this thread already why DNSSEC won't ever get transparency logging.

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

#144

Post by agwa »

tptacek wrote: post #142
agwa wrote: post #134

Earlier quoted context omitted.

That is not true. CAs are not required to log their certificates. Instead, Chrome and Safari by default do not accept certificates unless they are accompanied by a signed receipt from a recognized log. If you don't need your certificate to work in a default-configured Chrome or Safari there is no need for your certificate to be logged. Source: I work in this space

Here what you really mean is "if your certificates will never touch Chrome", because it's not just that Chrome won't accept them, but that Chrome's SCT auditing is part of a surveillance system for certificate misissuance.

I'm not sure what you mean by "surveillance system for certificate misissuance". Chrome's SCT auditing has nothing to do with detecting certificate misissuance; just misbehaving logs.

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

#145

Post by tptacek »

agwa wrote: post #144
tptacek wrote: post #142

Earlier quoted context omitted.

Here what you really mean is "if your certificates will never touch Chrome", because it's not just that Chrome won't accept them, but that Chrome's SCT auditing is part of a surveillance system for certificate misissuance.

I'm not sure what you mean by "surveillance system for certificate misissuance". Chrome's SCT auditing has nothing to do with detecting certificate misissuance; just misbehaving logs.

I'm literally just waking up right now and typing this from bed (ignore what that says about me as a person) so cut me some slack if this makes no sense and I reserve the right to come back and "clarify" what I was saying but: if Chromes see a Sectigo certificate for (say) Facebook.com with no SCTs, Google is going to notice.

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

#146

Post by tptacek »

belorn wrote: post #140
hsbauauvhabzb wrote: post #32

In 2020 I scraped fortune top 500 companies for dnssec and found iirc one domain using dnssec. It certainly feels like the wrong way of solving problems (ramming more into the domain registry always seems like a bad option). Is the technology dead or destined to fail? Edit: rationale: dnssec solves domain validity, but https tls solves almost the same problem but has better backing (azure said they don’t support dnss…

DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp hijacking of the root servers they would still not resolve.

Who cares? If you control BGP, you control the meaning of the IP addresses DNS resolves to.

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

#147

Post by tptacek »

teddyh wrote: post #131
rakoo wrote: post #119

Earlier quoted context omitted.

Wrong, TLS security is independent from DNS. If my threat model includes nation states I'll trust my own certificates or my very own CA.

By trusting certificates, you implicitly trust all CAs, not just your own.

You trust your browser's root program, not "all CAs".

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

#148

Post by agwa »

tptacek wrote: post #145
agwa wrote: post #144

Earlier quoted context omitted.

I'm not sure what you mean by "surveillance system for certificate misissuance". Chrome's SCT auditing has nothing to do with detecting certificate misissuance; just misbehaving logs.

I'm literally just waking up right now and typing this from bed (ignore what that says about me as a person) so cut me some slack if this makes no sense and I reserve the right to come back and "clarify" what I was saying but: if Chromes see a Sectigo certificate for (say) Facebook.com with no SCTs, Google is going to notice.

Nope. If Chrome sees a certificate with no SCTs, it rejects the certificate but doesn't report it to Google. (Except possibly for telemetry.) Google doesn't care if CAs issue certificates without SCTs; in fact, some CAs routinely do so for customers which want to keep internal hostnames private. (e.g. https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpra...)

SCT auditing only takes place if a certificate has SCTs. SCT auditing checks to make sure that the log really published the certificate. If it didn't, then the bad SCT is reported to Google so the log can be kicked out of Chrome.

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

#149

Post by toast0 »

AndyMcConachie wrote: post #114
toast0 wrote: post #92

Earlier quoted context omitted.

If the US is going to seize cryptographic material from CAs, they've probably got no problem ordering US based domain registries to do their bidding either. If it's Verisign registry, they can use the Verisign CA too, and it's only one company to compel. If all else fails, ICANN runs the root servers more or less, and is based in the US, and subject to being compelled to make bad signatues of tld glue records.

First off, ICANN doesn't run the root servers. ICANN operates 1 root server identity,l-root.root-servers.net. The others are run by different organizations. Secondly, the root server operators have no control over the cryptography. They get a zone file and they serve it. ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few mo…

> ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures.

Ok, well back to compelling Verisign. Certainly they are able to sign zones, although that authority flows from ICANN.

> Finally, glue records aren't signed!

If glue records aren't signed, then why wouldn't an adversary simply modify the glue records to omit the DNSSEC content? Maybe you're making a technical argument that the whole root zone is signed, not its individual components?

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

#150

Post by acdha »

fomine3 wrote: post #60
acdha wrote: post #50

Earlier quoted context omitted.

> Browsers did ignore most certificate errors back in the early 2000s. HTTPS sites were fairly rare and most people did not care about it or even considered https to be a negative. Many administrators considered it as bad technology that only increased instability with no obvious benefit. I’m not sure what you’re basing that on but every claim is the opposite of my experience back then. Even in the 90s it was expecte…

Old certification invalid dialog was terrible. I believe most people just ignored it. https://cdn.appuals.com/wp-content/uploads/2018/11/identity-...

Yes, that’s why I found the assertion that it didn’t exist so odd since almost anyone who supported web sites or browsers back then was familiar with that dialog.
Post reply on HN