Live data from Hacker News

For DNSSEC

blog.easydns.org

61–70 of 81 posts

Re: For DNSSEC

#61
post #57

The authors of this post missed the fact that there's an FAQ linked to the top of the post, where I rebutted all of these objections (and many better ones) 8 months ago. Rather than tediously recapping the same points again, I'll just direct their attention to the link: http://sockpuppet.org/stuff/dnssec-qa.html Dan Kaminsky, speaking at the Black Hat CSO Summit this Tuesday, attempted to advocate DNSSEC to the room.…

Also see my other HN thread on how to fix it.

Re: For DNSSEC

#62
post #57

The authors of this post missed the fact that there's an FAQ linked to the top of the post, where I rebutted all of these objections (and many better ones) 8 months ago. Rather than tediously recapping the same points again, I'll just direct their attention to the link: http://sockpuppet.org/stuff/dnssec-qa.html Dan Kaminsky, speaking at the Black Hat CSO Summit this Tuesday, attempted to advocate DNSSEC to the room.…

I tried to address all the major points in your FAQ and Adam Langley's follow-on blogpost as well, but I will take another crack at it.

Re: For DNSSEC

#63
post #43

Earlier quoted context omitted.

> And even if you choose a decentralized DNS solution, you still need DNSSEC. But that's not true. DNSCurve does provide a decentralized trust mechanism. If you are willing to embrace the pitfalls and advantages of such an approach, you don't need DNSSEC.

As covered in TFA, DNSCurve provides encryption between a DNS resolver and the client. It doesn't allow domain owners to sign their records. Dan Kaminsky did a good job taking DNSCurve apart back in 2011: http://dankaminsky.com/2011/01/05/djb-ccc/ "I observe this is essentially a walk of Zooko’s Triangle, and does not represent an effective or credible solution to what we’ve learned is the hardest problem at the inte…

"If you are willing to embrace the pitfalls and advantages of such an approach, you don't need DNSSEC."

That was in reference to Zooko's Triangle. You have to choose one of the other two if you are doing decentralized. The obvious choice being that you can't trust the human readable host names.

Re: For DNSSEC

#64
post #38

Earlier quoted context omitted.

Don't think so.

I believe so: http://dankaminsky.com/2011/01/05/djb-ccc/#whitelies (Phreebird is an online signer, but I don't see why an offline signer couldn't generate these proofs.)

Because you can't predict offline which names you need to obscure with fake NSEC records.

If there is any company in the world actually using Phreebird in production, I'd --- for more than one reason --- like to know about it.

Re: For DNSSEC

#65

Earlier quoted context omitted.

Ah, that makes sense. Sorry for the confusion I created. I meant that DNSSEC PKI is wrong in the sense that it is hierarchical, and the root keys are centrally controlled by a biased party. A better PKI would probably look like Convergence [1], where trust is derived from a hybrid CA/"web of trust" system formed by a network of notaries. The delegation implemented in DNSSEC is a good thing. I didn't think about how t…

Marlinspike abandoned convergence a year after it was debuted. It's currently broken on most (all?) platforms. As covered in the article, Convergence-style triangulation of cryptographic information is application/protocol neutral. Indeed, a DNS-level implementation would be much more powerful than what can be accomplished with HTTPS.

He moved from Convergence to TACK, which is on hold during the rollout of HPKP, which is like 80% of the value proposition of TACK.

Re: For DNSSEC

#66
post #52

Earlier quoted context omitted.

Yes.

That would force companies to either own all of the front-end server farms or store their keys on machines in untrustworthy environments.

Yes: a choice between two very unattractive options. Isn't DNSSEC great?

Re: For DNSSEC

#67
post #65

Earlier quoted context omitted.

Marlinspike abandoned convergence a year after it was debuted. It's currently broken on most (all?) platforms. As covered in the article, Convergence-style triangulation of cryptographic information is application/protocol neutral. Indeed, a DNS-level implementation would be much more powerful than what can be accomplished with HTTPS.

He moved from Convergence to TACK, which is on hold during the rollout of HPKP, which is like 80% of the value proposition of TACK.

What’s in the missing 20%?

Re: For DNSSEC

#68
post #64

Earlier quoted context omitted.

I believe so: http://dankaminsky.com/2011/01/05/djb-ccc/#whitelies (Phreebird is an online signer, but I don't see why an offline signer couldn't generate these proofs.)

Because you can't predict offline which names you need to obscure with fake NSEC records. If there is any company in the world actually using Phreebird in production, I'd --- for more than one reason --- like to know about it.

I don't know of any either, but there are plenty running PowerDNS in online 'white lies' signing mode. And then, of course, there is Cloudflare.

(And indeed, it cannot be done offline - although doing much narrower NSEC/NSEC3 ranges than 'normal' could be done offline).

Re: For DNSSEC

#70

Earlier quoted context omitted.

Signing DNS records using a machine connected to the internet, instead of passing the zone files to an air-gapped signing machine over a sneakernet. Eventually, you run into the issue of updating the "offline" machine and many places just have an "online" machine that gets the zone files through a highly restricted interface.

We're currently working on providing DNSSEC for our customers. The problem with only signing is that we really don't want all the keys to be physically present on our DNS servers, as many of them are hosted in other companies data centres. Having a central online signing server is bad for availability, as DNS down time is really not acceptable. That basically only leaves offline signing.

So have three online signers.
Post reply on HN