Hacker News Reader

Comment by tptacek | Hacker News Reader

Nothing about DNSSEC should concern you other than the prospect that it might someday actually be deployed.

http://sockpuppet.org/blog/2015/01/15/against-dnssec/

I wonder why moxie's Convergence [0] didn't take off. To me it sounds near-perfect. It could handle multiple layers of authenticity, including DNS.

The project has been inactive on GitHub for 5 years [1], however the Namecoin project picked it up [2] as "FreeSpeechMe" and added support for IPv6, and .bit, .onion, .b32.i2p domains. Now this, too, has been discontinued "because Mozilla removed the relevant API's as of Firefox 33". They "intend to release a replacement soon". According to Jeremy Rand [3] "A replacement is in the works (and is mostly working already)", but the source doesn't seem to be public or I can't find it.

Are there any downsides of Convergence?

0: https://www.youtube.com/watch?v=Z7Wl2FW2TcA

1: https://github.com/moxie0/Convergence/

2: https://github.com/namecoin/Convergence/

3: https://twitter.com/biolizard89/status/712525859194798080

> Are there any downsides of Convergence?

Your web browser grinds to a halt because almost no one runs a notary. I tried using it for a while.

IIRC, Google didn't want to run it because they'd end up running all the notaries themselves, which they didn't want to do.

So according to this and CiPHPerCoder's comment, the only reason it didn't take off is that it didn't take off?

Edit: found the comment from Adam Langley [0]. They didn't want to add it to Chrome because it wouldn't meet standards for the preferences UI inclusion, practically everyone would just rely on the default notaries, so Google would have to guarantee notary uptime, thus being forced to run them on their own.

He doesn't really point out why they don't include it as an optional alternative without any notaries pre-configured. He does however say that running it as an extension would be fine, but the required APIs weren't available at the time of writing.

0: https://www.imperialviolet.org/2011/09/07/convergence.html

To me, HPKP, surveillance, and God willing a better UX for certificates would get us 80% of the way to Convergence.

One big challenge was it didn't account for gated hotspots (hotels, Starbucks, etc) where you need to authenticate to reach the Internet.

I like it too. The cons just don't exist in my pow:

one downside was that it didn't work on things like airport access points, but those break regular tls too.

an other downside was the fact that google didn't want to integrate it in chrome because the notaries would have to be always up. now they run transparency logs that have to be always up anyway. so.. what's the difference?

The Perspectives Project piked up the idea, and it seems less dead that Convergence: https://perspectives-project.org/

If you're going to spread the "Against DNSSEC" FUD, it would be useful to give people the opposing viewpoint:

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

It's also worth pointing out that DNSSEC enables, for example, improvements to OpenPGP key discovery:

https://tools.ietf.org/html/rfc7929

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

See in that (old) thread the author's attempts to salvage those arguments. Zach followed up with me after that thread, by the way, and apologized for the tone of the original post you just relayed to this thread. I told him that was unnecessary, because I have no intention of ever being nice about DNSSEC. :)

Exactly what I'm hoping for, by the way. Sounds great. A PKI, controlled by the US Government, with 1024 bit RSA at the top, somehow connected to my PGP keys.

I don't demand that you be "nice about DNSSEC". :) But if you want to be credible then it might help if you said something more accurate than "1024 bit RSA".

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

"1Kb keys are temporary and the industry is already migrating to 256-bit ECC."

http://blogs.verisign.com/blog/entry/increasing_the_strength...

"With this change, the root zone ZSK size will match the size of the KSK: both will be 2048-bits. One difference, however, is that the ZSK is changed (rolled) four times per year, or approximately every 90 days. The root zone will not be the first to use a 2048-bit ZSK. Approximately 60 top-level domains (TLDs) are known to be using 2048-bit RSA ZSKs already."

That's your comeback? "You're wrong, the RSA-1024 is only temporary, and only used at the root of the tree"?

The prosecution rests.

If you read the "Deployment Schedule" in that second link, you'll see "Sept. 20 [2016]: The first 2048-bit ZSK will be pre-published in the root zone."

Looks like the prosecution might only have a few weeks of rest. :)

It's the second half of 2016 and the best argument you have for DNSSEC is that they've at least scheduled the start of the removal of 1024 bit RSA keys for later in the year.

I'm pretty comfortable with what this thread says about our respective credibility.

That's great, but if you really wanted to clear up any doubt about your credibility, could you provide an estimate for how much it would cost an adversary to crack a 1024 bit RSA key within 90 days? You seem to suggest that's a significant threat that has to be addressed before anyone uses DNSSEC.

There isn't any doubt about tptacek's credibility.

He points out how dnssec puts control in the hands of whatever government controls the domain, and your counter argument is about the strength of keys used to do so.

It makes your argument seem less like an argument on the merits of the issue and whether or not tptacek is a credible voice in the matter. Further, to call his arguments FUD takes you further down a path that is not increasing your own credibility.

The question of whether DNSSEC "puts control in the hands of whatever government controls the domain" was addressed in the first link I sent:

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

Basically, whereas any CA (controlled by any government) can issue a certificate for any domain, with DNSSEC you at least get to pick which government you trust to secure your domain (or run your own generic TLD and not trust any government).

My counter argument about the strength of the keys was because he was the first to mention "1024 bit RSA". Did you miss that?

Finally, I used the term "FUD" to borrow the language from that EasyDNS article, the second sentence of which is: "Sadly, there is a lot of FUD out there and we wanted to both debunk that FUD and explain why DNSSEC is vital to the security of the internet." Hopefully people are reading both sides of the story here.

The best argument for DNSSEC is that it can be used to enable specific key discovery (and not in any actual security that it's providing per se). But it's not entirely clear that it's a good idea for that auxiliary purpose. Distributing PGP keys arguably would work better if you had the SMTP server report PGP keys when available (obviously, verification would have to come via external means). It certainly would be far faster to deploy this sort of "useful" service in an application-level protocol that all interesting clients already deal with, as opposed to requiring looking up another protocol that can be harder to access with standard APIs.

Reply on news.ycombinator.com