Live data from Hacker News

DNSSEC KSK rollover breaks DNS resolution for .nz domains

status.internetnz.nz

81–90 of 181 posts

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

#81
post #73

Earlier quoted context omitted.

All the CAs are required to log. You don't have to trust any of them. The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.

Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome. For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long migh…

> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients.

Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's never (or more accurately, never has to be) the client actually doing the reporting. Reporting is left to separate monitoring parties.

In other words: a global adversary cannot surreptitiously use a novel CA against a particular configuration; they must first make themselves visible to one or more CT logs. Failing to do so means that their CA will be rejected outright by the client (or accepted by the client if the client doesn't do CT, but still with a loss of stealth).

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

#82

Earlier quoted context omitted.

Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome. For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long migh…

> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's nev…

The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates.

Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.

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

#83

Earlier quoted context omitted.

> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's nev…

The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates. Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.

That's not how any of this works. Clients don't download the CT logs.

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

#84
post #83

Earlier quoted context omitted.

The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates. Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.

That's not how any of this works. Clients don't download the CT logs.

Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding.

The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.

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

#85
post #83

Earlier quoted context omitted.

That's not how any of this works. Clients don't download the CT logs.

Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding. The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.

I don't think you're providing clarity at all, because that attack doesn't work.

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

#86
post #85

Earlier quoted context omitted.

Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding. The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.

I don't think you're providing clarity at all, because that attack doesn't work.

If you wanted to use your words to explain why you think that, that might be more constructive. I could well respond "yes, it does work" but that wouldn't be useful. I know you're an expert in the space and might appreciate learning from you, but this is not that.

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

#87
post #83

Earlier quoted context omitted.

That's not how any of this works. Clients don't download the CT logs.

Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding. The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.

No, because the presented certificate won't have any SCT entries (which are embedded in the certificate), and you can't fake the SCT entries without having access to the CT private keys.

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

#88
post #77

Earlier quoted context omitted.

I'm not sure why you're so fixated on this idea of client systems monitoring CT logs. Operators who host infrastructure can and should be monitoring issuance in CT logs for domains they operate, which will allow them to identify and react to any unexpected issuance for those domains.

In the attack DNSSec prevents, a client is compromised by a cert that doesn't appear in the CT logs, so infrastructure monitoring is irrelevant.

Most browsers will reject such a certificate. See https://googlechrome.github.io/CertificateTransparency/ct_po... for the policy Chrome imposes - my understanding is that Safari is broadly similar. Right now I don't think Firefox performs this validation, so this is possible if you know in advance that your target runs Firefox.

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

#89
post #53
post #52

DNSSEC is easily the worst upgrade, multiplying complexity and brittleness, with the least amount of net benefit (without even adding encryption), that could have been solved in much simpler ways, that the Internet has ever attempted -- and that's including IPv6 (which is now quite workable). Speaking as someone who most people consider a DNS expert and actually did help develop and deploy something substantially add…

At this point it feels like DNS should be given to Cloudflare or Google and let them design it from scratch. I'm only half joking.

For sure. DNS is definitely something that should either be canned after 2 years, or protected by 50 captchas.

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

#90
post #9

Earlier quoted context omitted.

Fortunately, New Zealanders benefit from all of the problems solved by DNSSEC.

Isn't DNSSEC basically obsoleted by DoH?

In the same way that TCP is obsoleted by WebSockets. Personally I'd prefer a solution which is neither of them.
Post reply on HN