Hacker News Reader

> * DANE is effectively a key escrow system. COM's keys would be held by the USG.

They can already temporarily change DNS records and get certificate from any legitimate CA.

> * In the same vein: people with cosmetic TLDs like .LY would be forced to concede their TLS policy to governments like Libya.

They already are doing this, see first point.

> * The "last mile" on DANE is spoofable, because DNSSEC doesn't protect the link between browsers and DNS servers; it's a "server-to-server" protocol. In particular: your ISP could still override pins!

Run a local resolver. If you have trusted server some you can use DNS over TLS.

* DANE doesn't actually work in practice, because of all the networks that block odd-looking DNS lookups; this is Adam Langley's point from "Why Not DANE In Browsers".

Then these networks are bad. For what reason network should be interested with more than UDP/TCP layer in DNS packet? Again, you can use DNS over TLS.

For other readers, look at discussion in https://news.ycombinator.com/item?id=12382752

Regarding your first point: no, they can't. See what happens if they try to exploit the DNS to get a Google certificate. (Notice the last several years of Google punishing CAs).

It is very important to DNSSEC advocates to convince people that our security can't be any better than the security of the .COM zone, which is controlled by the US Government through Verisign. But nobody accepts that level of security today. Arguments that we can escrow all our security with Verisign are DOA, post Snowden. Move on.

Regarding the rest: you can't persuasively rebut arguments by conceding they're correct.

> Regarding your first point: no, they can't. See what happens if they try to exploit the DNS to get a Google certificate. (Notice the last several years of Google punishing CAs).

What? Article about it on HN? They won't punish CAs for that, because that won't be CA fault that USG modified DNS zone.

> It is very important to DNSSEC advocates to convince people that our security can't be any better than the security of the .COM zone, which is controlled by the US Government through Verisign. But nobody accepts that level of security today. Arguments that we can escrow all our security with Verisign are DOA, post Snowden. Move on.

Because it can't be better with DNS, which is by design hierarchical. You would have to create own domains as TLD in root zone. Oops, you now have to trust root zone owners! So you can create blockchain based domain system. But, it won't be DNS. And you will argue that implementing blockchain name system is even more expensive to implement than DNSSEC, because it is slow and requires big storage space.

> Regarding the rest: you can't persuasively rebut arguments by conceding they're correct.

Last mile problems aren't covered with DNSSEC, there is other RFC for that.

You've missed my point. The reason you can't DNS spoof to obtain a Google certificate is that the certificate is pinned, and CAs are monitored (through both pins and through CT).

The rest of this comment continues to concede the arguments I made previously, but pretend that those concessions are rebuttals. It's really only in DNSSEC threads that I notice this peculiar rhetorical strategy deployed.

> Regarding your first point: no, they can't. See what happens if they try to exploit the DNS to get a Google certificate. (Notice the last several years of Google punishing CAs).

If the U.S. government, or the Russian government, or the Luxembourgian government orders a CA subject to it to produce a certificate for a given key and hostname, it will be given a certificate for that key and hostname.

If the U.S. government, or the Russian government, or the Luxembourgian government orders a DNS provider subject to it to resolve all requests for a domain to a different IP than it would have otherwise, those requests will be so resolved.

If the U.S. government, or the Russian government, or the Luxembourgian government orders a network subject to it to route all traffic for one IP to a different IP it controls, that traffic will be so routed.

> It is very important to DNSSEC advocates to convince people that our security can't be any better than the security of the .COM zone, which is controlled by the US Government through Verisign. But nobody accepts that level of security today.

Everybody accepts that level of security today, because that's the level of security we have today.

Actually, it's better than the level of security we have today, because at least a DNS-level CA system would mean that no-one other than someone who can compel .com can take over a .com hostname. Right now any government in the world can do so, at the drop of a hat.

Restricting that to the government a company or person is subject to greatly reduces the attack surface.

If the US government orders a CA to mint a bogus certificate for Google Mail, they will get the certificate, and then the CA will get put out of business, one way or the other.

There are consequences to suborning the TLS CA system. DNSSEC advocates pretend there aren't, because they have to, or their arguments become untenable, because there cannot plausibly be similar consequences for suborning the DNS: we know for a fact, with repeated existence proofs, that governments will manipulate the DNS (like DOJ did with file sharing sites), and we know .COM isn't going anywhere.

DNSSEC advocates will grudgingly acknowledge one half of the modern CA system security model: key continuity (pinning).

What they seem unable to acknowledge is the other half. To use Moxie Marlinspike's terminology, which he coined in an argument against DNSSEC: trust agility.

> If the US government orders a CA to mint a bogus certificate for Google Mail, they will get the certificate, and then the CA will get put out of business, one way or the other.

Probably, but in the year (or more considering that startSSL is still trusted) until the CA's trust is removed, that certificate still works.

Besides, if you accept that governments manipulate DNS, why do you deny they manipulate DNS to get domain validated certificates? Cause if not, we are back at trusting verisign for all websites that aren't statically pinned. (with that added 'bonus' that those statically pinned sites can be wrecked by their pin at any time)

> we know for a fact, with repeated existence proofs, that governments will manipulate the DNS (like DOJ did with file sharing sites), and we know .COM isn't going anywhere.

Yeah, like I've posted before, this is actually US gov SOP.

The US government asserts super-jurisdiction over .COM/.NET/.ORG and will seize such domains at will [1] [2] [3], which should make every non-American think twice about using those TLD's for anything. Your only recourse will be the American justice system that you will have to navigate as a foreigner. Meanwhile, ccTLD's are under the jurisdiction of their respective countries. Of course, the US is still ultimately in control of the root zone, but I consider messing with that the nuclear option after which the US will surely have to hand it over to the UN as has been discussed at times.

[1] https://yro.slashdot.org/story/12/03/06/1720230/us-asserts-s...

[2] https://en.wikipedia.org/wiki/Domain_name#Seizures

[3] https://en.wikipedia.org/wiki/Operation_In_Our_Sites

Sure, Google is defended, as are some other big sites. However, this isn't a scalable solution. Are you really going to argue that the sites small enough not to be statically pinned don't deserve to be safe from state-level attacks?

No? That's what HPKP does: it allows sites of any size to pin certificates.

I'd say the article shows plenty of issues with HKPK. It also forgoes the fact that HKPK only works on the second visit.

For that one user. But part of the point of HPKP is that it raises the stakes for CAs who would issue bogus certificates: someone will have their pin broken, browsers will notice, CAs will be forced into CT or worse.

I have kinda lost faith in the stakes for CAs. It seems like they have to fuck over a really big client for anything to happen.

In general, the CA system is fucked and we need a new one. Note that I never said DANE should be the replacement for CAs. Instead I wanted DANE pinnen to replace HPKP.

I wonder if any if this is even relevant when you consider downgrade attacks.

Everyone has lost faith in the CA system. The problem is that DANE doubles down on it by creating a new hierarchical PKI, this time de jure controlled by governments. And it's not even a good PKI! It's a PKI built around 1990s cryptography.

DANE is not the answer.

Mandatory CT and enforcement of CA Baseline Requirements by browsers is the immediate step. A decentralized trust model is the step after that. None of these steps require the USG to escrow our keys.

DANE doesn't quite double down, it reduces the attack surface to your TLD, instead of all CAs. It sucks as a replacement to CAs. However, when it comes to pinning, it is an alternative to HPKP that avoids the costs mentioned at the article, giving up power to the TLD as the price.

In any case, I wouldn't mind if the USG was one of the parties that get to vouch for my key. Many attackers don't have control over the USG. Obviously, that requires multiple other parties that also vouch for my key.

I'm also quite interested in what you think the decentralized trust model looks like. Specifically, the out-of-the-box experience.

> DANE is effectively a key escrow system. COM's keys would > be held by the USG.

That is one mode of DANE. There is also a pinning mode of DANE, where you restrict what certificates can be used to sign yours. This is then an add-on to the CA system, so you'd still need to convince a CA to give you a certificate to MITM.

Besides, as others have said. Those same DNS servers can already break the current systems as they can simply rebind and get a certificate through any CA.

> The "last mile" on DANE is spoofable The last mile is only spoofable if you don't locally run a DNSSEC validating resolver. This is easy enough to set up.

> DNSSEC is far, far more expensive to deploy than HPKP (HPKP is just a header you add to your web server configuration). Does that hold when you take into account the safeguards required to sanely setup HPKP? I'd say the article explains quite well the issues with deploying HPKP.

Sure, DANE and DNSSEC aren't going to replace the CA system. They can certainly complement it though.

If you don’t trust the DNS, you’re pretty much screwed anyhow. The solution to the “last mile” problem is to run a private resolver on each machine. The DNSSEC root KSK (master) key is 2048 bits, and the ZSK is due to change to 2048 bits this year, after careful consideration of all the factors.

First: no, not only is it not true that we must trust the DNS, but not having to trust the DNS is literally part of the thesis statement of SSL/TLS.

Second: you only need to break the weakest of the keys to attack the system. It's 2016, and we're talking about deploying a system that aspires to RSA-2048 or ECDSA, both of which are outmoded.

It actually gets worse. DNSSEC was designed in the mid-1990s with the assumption that cryptography was too expensive to deploy at scale. It's for this reason that DNSSEC uses signing-only constructions and requires support for offline signers: that is, support for people who will sign once, offline, and then never touch cryptography again.

All sorts of badness flows from support for offline signers. In particular: DNSSEC responses themselves are not encrypted. Despite relying on the most expensive cryptography primitive (public key signatures), the protocol offers no privacy at all.

This would be funny if it weren't for the fact that it turns out you need online signers anyways. Without online signers, there's no way to simultaneously (a) authenticate negative responses (ie: prevent someone from spoofing an NXDOMAIN response) and (b) not reveal all the names in a DNS zone. Surprisingly (at least to the people on the working group), pretty much everyone demands (b), and so pretty much every real-world DNSSEC deployment is an online-signer, so that it can synthesize NSEC records to trick out people trying to dump zones.

It's an incoherent protocol that deliberately handicaps itself in an attempt to achieve a design objective that turns out not to be possible to achieve.

Moreover: the more DNSSEC gets deployed today, the harder it will get to deploy fast, modern, misuse-resistant curve signature schemes. That's because anything you try to deploy on DNSSSEC needs to be supported by pretty much all the DNSSEC resolvers, because DNS is an infrastructure protocol, not an application-layer protocol.

It's for the same reason that DNSSEC failures cause sites to vanish completely from the Internet rather than generating pop-up warnings.

> First: no, not only is it not true that we must trust the DNS, but not having to trust the DNS is literally part of the thesis statement of SSL/TLS.

Uh. Certificates are issued by checking DNS entries, and you are saying that we don't have to trust it.

That is correct, yes.

Your usual example here is how hard it is to get a domain-auth cert for google.com, but what about a small e-commerce site? What should they do to prevent a bad guy from getting a domain-auth cert by spoofing DNS? Honestly asking for my education (and others).

They should get an OV cert and use HPKP for their domain. That is: if they're worried that a state-level attacker is going to MITM their users with a fake certificate.

Thanks. Is that attack only available to state-level attackers? I thought that--absent the measures you detail above--it was possible for a criminal enterprise to fool a CA into issuing a domain-authenticated cert.

The attack is too complicated for fraudsters, because it's multi-stage. They have to perpetrate a heist to get the certificate, and then another heist to MITM people to use the certificate (you can potentially use the DNS for both attacks, but they're still different attacks). DNS spoofing is not common in the real world, because it has low payoff.

Thank you.

OV certs do almost nothing to prevent MITM attacks. Unless you expect users to recognize when an OV cert is replaced with a DV one.

Moreover, HPKP means that I have to trust my first visit to a site. Any new site could be MITMed. Heck, HPKP means that anyone that gets to MITM your domain can wreck it for however long a Pin is valid.

It's easy to "win" arguments if you cherry pick parts of them and ignore the rest.

It's easy to "win" arguments if you try to come of better, rather than seeking for mutual understanding.

(yep, this ain't really seeking for mutual understanding)

And how do you get a TLS certificate? By… proving that you control the DNS. Come back when there’s a working attack against the crypto of DNSSEC; being “outmoded” is not a security flaw. DNS is, on a very fundamental level cached, by slave servers, who does not, and should not, need to have access to the DNSSEC key to do live signing of records. DNSSEC was made for security, and explicitly not encryption – bringing up its lack of encryption like it’s a fundamental flaw in DNSSEC is a strawman argument. Regarding enumerating zones, you do know of the NSEC3 record (widely deployed for years) and the work on NSEC5, right? They were made to fix that, and, as I understand, were successful. Arguing against DNSSEC because we could in theory have something better reminds me of those arguing against SSL because the CA model is flawed. Sure it’s not perfect (what ever is?) but it’s what we have, and it’s better that the practical nothing we would have if we keep arguing about theoretical perfection over actual deployment of working code.

You are like the 9th person on this thread to make the same banal point about the relationship between DV certificates and the DNS. It's not accurate. See: rest of thread.

I don't so much mind people making the same arguments over and over again on different threads, but when you can read the thread and see the clever point you're about to make has already been litigated, I'm less sanguine.

You keep offering HPKP as a solution in a thread regarding an article that shows how HPKP sucks. Hence why we keep repeating the same point.

The article doesn't show that HPKP "sucks". The article shows that HPKP can be dangerous. PKP isn't going anywhere, and we've been relying on it for years: it is likely that at least one CA has been penalized for breaking PKP pins.

This is very much unlike DNSSEC. True statement: we could publish the secret keys for the root ZSK on Pastebin today, and nothing on the Internet would break, because nobody relies on DNSSEC for their security.

Protocols that require online signing are impossible to cache and hard to scale. Even OCSP is often used with pre-produced offline signed responses for that reason (but they are periodically re-signed of course). So that's probably why DNSSEC supports offline signatures.

And while I agree that confidentiality of DNS would be a step in the right direction, there would still be many other leaks, e.g. the SNI field in TLS, or the destination IP address. To completely hide who is accessing which site, you'd need some kind of mixnet or onion routing.

If you find any of these points convincing, please have a look at this FAQ, esp. the DANE section:

http://blog.easydns.org/2015/08/06/for-dnssec/

This is the third time you've posted this link (and that's fine; it's far from the third time I've written an anti-DNSSEC comment --- though I do take the trouble to rewrite them each time).

Each time, I'm going to point out that the author of that

(a) there was an HN thread that addressed it:

https://news.ycombinator.com/item?id=10019029

(b) the author of the post actually mailed and apologized for its tone. I don't know how much of it they continue to stand by, but I think they might write it differently now regardless.

(I reserve the right to cut/paste this particular comment in the future).