Hacker News Reader

Comment by byuu | Hacker News Reader

> Currently, web-based applications must use browser extensions to take advantage of advanced DNS features such as DANE, DNS-SD service discovery, or even to look up anything other than IP addresses. Extensions for features that depend on DNSSEC must validate it themselves, as the browser and the OS may not (be able to) validate DNSSEC.

If only there were some way for Google to let people take advantage of advanced DNS features without requiring browser extensions ... alas, they'd probably need to add that code to a web browser. But then, where would they find a web browser they could add such code to? Ah well. Google should ask those web browser vendors why they won't implement DNSSEC, at least. Maybe start with asking the browser with the highest market share, whichever that one is.

View on HN

agl has explained in detail why they don't do that: https://www.imperialviolet.org/2015/01/17/notdane.html

tl;dr they can't, because DANE is undeployable in the current Internet.

Thank you for the link. I was previously only working from these links:

https://www.ietf.org/mail-archive/web/dane/current/msg06996....

https://bugzilla.mozilla.org/show_bug.cgi?id=1077323

https://bugs.chromium.org/p/chromium/issues/detail?id=50874

> Instead, for this we have HPKP, which is a memory-based pinning solution using HTTP headers.

The problem with HPKP is that you still need a certificate from a CA. And if you want wildcards or a >90 day length (regardless of what you think of their security, many people do -- the biggest sites on the internet have both), that means paying money. And it also still leaves you vulnerable to MitM rogue CA attacks.

HPKP requires the user to connect the first time to get the pinned key. If an MitM has a fake certificate for your domain, they can send that to you on your first connection and fool you. DANE does not have this problem.

Well, to be fair, DANE has it for the DNSSEC provider used. But that is one thing to trust, and said certificate can be bundled with the OS or browser. One thing to trust beats the current 2000+ intermediate CAs we have to trust.

Further, DANE allows a way to verify self-signed certificates, allowing security to be free for everyone. We could see a lot more innovation than just certbot if Let's Encrypt weren't the only way to generate free certificates. For just one example, web servers could generate certificates from fresh installs; zero configuration requied. Like Caddy, but in nginx and Apache.

Lastly, HPKP is riskier. You have to include a backup pin. But, what would happen if your had your own pinned, and StartSSL as the secondary? And you set HPKP for a year? And two weeks from now, Mozilla revokes StartCom entirely? Well, good luck with that one. Deleting HPKP is a royal pain for a regular user (about:permissions in Firefox, chrome://net-internals#hsts in Chrome)

> We also have pre-loaded pinning in Chrome for larger or more obvious targets.

Nice for Google and Facebook, not so nice for byuu.org =(

> It's also worth noting that CryptoCat has committed pinning-suicide in Chrome at at the moment due to their CA having switched intermediates between renewals.

Another good negative of HPKP.

> But support for that was removed because it was a bunch of parsing code outside of the sandbox, wasn't really being used and it conflicted with two long-term plans for the health of the HTTPS ecosystem: eliminating 1024-bit RSA and Certificate Transparency. The conflicts are probably the most important reasons for not wanting to renew the experiment.

RSA-1024 is bad, yes. Perhaps we should start asking how we can get DNSSEC on RSA-2048+. Having a commitment to implement it in Chrome, Firefox, Edge, Safari if we do would go a long way toward making that happen, I'm sure. Further, we can reject any RSA-1024 signed DNSSEC after that point, just like we reject weak crypto in browsers today.

If they can't change DNSSEC to stronger crypto, how about they make an alternative? If Google introduces one that has stronger crypto, supports it in Chrome, and offers a free "DNSSEC+" hosting service, I'll definitely take immediate advantage of that.

But the latter is the whole point of DANE -- self-signing. Certificate Transparency is a crutch due to the CA system having 2000+ intermediate CAs that can sign any domain name they want. With DANE, you don't need that anymore. DANE is about providing an alternative to the CA signing business.

And there's nothing stopping users from serving up trusted CA-signed endpoint certificate signatures over DANE/TLSA records. That would obviously remain the only sensible way to do EV certificates. The way I see it, a DANE certificate would act like HTTP does now: you get the globe (or even the question mark circle), but your page actually loads over HTTPS, instead of sending you to Defcon-1 advisories that are all but impossible for the casual user to work around (and indeed, we don't want to train them to work around these warnings anyway.) There's no way this would be worse than plain-text HTTP.

> You literally can't avoid it because the root zone transits through a 1024-bit key.

Does this really matter for the root? There are root CAs with RSA-1024 still.

...

At any rate, Google apparently feels DNSSEC+DANE is good enough for this web service API. So, honest question, why offer that if it's really such an unworkable system?

Note: They are already working on switching to 2048 bits in DNSSEC; they will do it some time this year, if all goes according to plan.

RSA1024 isn't as much of a problem for DNSSEC, though it is being increased. The validity period and the amount of data being encrypted restricts the attacker to a much larger degree. That being said, I don't think RSA is the correct choice anymore for speed, security, or size of DNS responses.

You can find more information here: https://www.cloudflare.com/dns/dnssec/ecdsa-and-dnssec/

I was definitely thinking, "why not use Curve25519 for a 256-bit key if fitting the response into one packet is so important?"

It seems there's some worry about quantum computers being able to break ECC with less qubits than RSA on account of there being less actual bits.

But to me, it seems like if quantum computers come about that start breaking things, RSA is going to need to be replaced as well. So now's probably not the time to be too paranoid about something we don't yet know will ever even happen. At least, not until we have something we know will be resilient to the new quantum attacks.

First, I have bad news for you, and good news for the Internet:

In the very unlikely event that Chromium or Firefox ever honor DANE records, and the even less likely event that they honor trust anchor assertions in TLSA, you are still going to need a CA certificate. In the parallel universe in which DNSSEC is seriously deployed and honored by browsers, the entire X.509 PKI will be replaced with something else before TLSA trust anchor assertions are reliably deployed in browsers, and, until they do, huge fractions of your user base won't know what the hell the DNS is talking about when you give it your self-signed certificate.

If you don't care about that user base, then nothing at all is stopping you from using self-signed certificates today. Just tell your group of friends and followers to check your certificate once when it pops up with a warning, and add it to their trust stores. If you tried to use parallel-universe DANE to serve a self-signed certificate, that is the experience you would have anyways.

"The whole point of DANE" is not self-signing. If it were, Dan York wouldn't be telling people that DANE isn't government key escrow (hint: it is) because the CAs will still be involved. The point of DANE is to come up with some reason, any reason, to get DNSSEC deployed, because the people working on it have in some cases been working on it for over 20 years (it shows) and are frustrated that the Internet has moved on without them.

I don't know what you mean by "Google feels DNSSEC+DANE is good enough for this web service API". The web service is a simple wrapper around a DNS service. The Google you want to pay attention to, the one that matters for the DANE discussion, is the Chromium project. Go talk to the Chromium security people about DNSSEC. See what they say.

That argument seems to boil down to “We can’t use any new record types in the DNS ever again because 4-5% of users had problems when we silently tested it”. First, this is defeatism writ large – if we can’t develop anything new, ever, we may all just as well go home and give up. Secondly, these things don’t exist in a vacuum; if a website failed because a user couldn’t access DANE or whatever, this would create pressure on all affected parties to fix the situation. This is how things progress instead of stagnates.

> First, this is defeatism writ large – if we can’t develop anything new, ever, we may all just as well go home and give up.

No, it means you need to consider the existing realities when designing a new protocol. A good example is HTTP/2: Probably countless proxies would produce crap once they see an HTTP/2 packet. So people came to the conclusion that they need to wrap HTTP/2 in TLS in order to deploy it. (I know that there's HTTP/2 without tls, but nobody is using it for precisely that reason.) HTTP/2 was built with deployability in mind. DNSSEC was not.

> Secondly, these things don’t exist in a vacuum; if a website failed because a user couldn’t access DANE or whatever, this would create pressure on all affected parties to fix the situation.

This is simply not what's happening. What happens in the real world is that people blame their browser for breaking things that previously worked. There are countless examples for this.

>What happens in the real world is that people blame their browser for breaking things that previously worked.

There are 3 browser vendors of any note right now. It wouldn't be that hard for them to collaborate to push this change at the same time.

Not necessarily. Consider the (admittedly dystopian) future where everything you do is hosted at Facebook.com. DNS becomes a vestigial remnant of the old Internet, and Facebook does de facto name resolution on it's private servers. New things can then develop within the proprietary Facebook ecosystem, in part because FB controls (more of) the entire experience. (Come to think of it, why doesn't FB develop a browser and an OS? And hardware while their at it. The fewer middlemen between you and your product the fewer risks you'll get cut off from them/it.)

The root zone ZSK is increasing to 2048 bits as we speak. http://www.circleid.com/posts/20160928_increasing_strength_o...

The article also mentions the number of TLDs that now use 2048 RSA keys is around 1,300.

It's 2016, and the DNSSEC people are congratulating themselves for removing a 1024 bit RSA key.

Progress!

By the way, since DNSSEC is always good for laughs, check which cloud platforms support DNSSEC currently (spoiler: none).

They also rotate the keys every 3 months, so the standard cost analysis is a bit different.

DANE is not DNSSEC. This API doesn't solve the problem the DANE is trying to tackle (adding additional trust vectors to certificates).

It actually seems kind of lazy. Their argument is that it is to difficult for client software to embed a DNS resolver into the browser so it can check whether DNSSEC was attempted and whether it was successful. The actual validation would still happen at the clients local resolver.

Their solution is to make client software implement a REST API for doing its lookups instead, and the validation is still happening at your resolver (the REST API).

The only thing I see as a positive with this is your DNS requests will be encrypted. The trade off is the complexity of the process of getting your responses and that you'll be subject to the potential of third party censorship, logging of all destinations which will be difficult to opt out of.

Reply on news.ycombinator.com