Live data from Hacker News

For DNSSEC

blog.easydns.org

21–30 of 81 posts

Re: For DNSSEC

#21
post #19

What does "moving on to ECC" in HTTPS have to do with the weak crypto in DNSSEC? It seems to me like they're brushing this issue aside, especially with their "but seriously, you don't really expect the NSA to spend tens of millions of dollars to crack a server's security, do you?" comment. Um, if it's a site that serves millions of people I most certainly do! I'd also expect them to spend that much on any tens of tho…

They are moving the ECC for DNS record signing, not HTTPS certificates.

Re: For DNSSEC

#22
So as I read #1, I'm trying to figure out what angle they're trying to argue here. The fact that the current TLD and CA systems are baked around the concepts of central authorities who are controlled either directly or indirectly by governments is known, and it's not a valid justification for DNSSEC also having that same pitfall. We're already well aware of the threats to security that come from centralized control like that, lets not build a new system that puts all our eggs in the same basket.

Re: For DNSSEC

#23
This is unconvincing. For instance:

"There are methods to prevent leaking" isn't the same as "leaking is prevented by default." This sounds like a protocol design flaw that will end with implementors being blamed.

I think the way forward is a protocol like Stellar, not one like DNSSEC. Also, EdDSA or GTFO

Re: For DNSSEC

#24

This is unconvincing. For instance: "There are methods to prevent leaking" isn't the same as "leaking is prevented by default." This sounds like a protocol design flaw that will end with implementors being blamed. I think the way forward is a protocol like Stellar, not one like DNSSEC. Also, EdDSA or GTFO

> "There are methods to prevent leaking" isn't the same as "leaking is prevented by default."

This is from the zone enumeration section and plain DNS doesn't do anything to prevent zone enumeration by default either.

> EdDSA

We are working on standardizing EdDSA, but it takes a long time to get to deployment.

Re: For DNSSEC

#25

This is unconvincing. For instance: "There are methods to prevent leaking" isn't the same as "leaking is prevented by default." This sounds like a protocol design flaw that will end with implementors being blamed. I think the way forward is a protocol like Stellar, not one like DNSSEC. Also, EdDSA or GTFO

> "There are methods to prevent leaking" isn't the same as "leaking is prevented by default." This is from the zone enumeration section and plain DNS doesn't do anything to prevent zone enumeration by default either. > EdDSA We are working on standardizing EdDSA, but it takes a long time to get to deployment.

Good, come back when it's standardized. Until then, stamps [REJECTED] on the DNSSEC folder death to 90's crypto

Re: For DNSSEC

#26
post #22

So as I read #1, I'm trying to figure out what angle they're trying to argue here. The fact that the current TLD and CA systems are baked around the concepts of central authorities who are controlled either directly or indirectly by governments is known, and it's not a valid justification for DNSSEC also having that same pitfall. We're already well aware of the threats to security that come from centralized control l…

The argument is that if you choose a traditional TLD your eggs are in the centralized basket. All of the mitigation techniques proposed by Marlinspike for HTTP can be applied at the DNS level as well.

And even if you choose a decentralized DNS solution, you still need DNSSEC.

The point is that DNSSEC has little to do with the centralization issue and that it can do a lot to improve the security and privacy of the Internet as a whole.

Re: For DNSSEC

#27
post #19

What does "moving on to ECC" in HTTPS have to do with the weak crypto in DNSSEC? It seems to me like they're brushing this issue aside, especially with their "but seriously, you don't really expect the NSA to spend tens of millions of dollars to crack a server's security, do you?" comment. Um, if it's a site that serves millions of people I most certainly do! I'd also expect them to spend that much on any tens of tho…

Where do you see that? The article seems to only talk about moving to ECC in the context of better DNSSEC security and message sizes that are an order of magnitutde smaller than RSA's.

Re: For DNSSEC

#28
post #16

With the current CA system, you have to worry about far more than just the CAs. An attacker just needs to MITM the connection between the target website and a CA of his choosing, and the CA will give the attacker domain-validated certificates for the target website. So the current SSL in browsers can be compromised not just by the 600+ CAs, but also by anyone who can launch MITM attacks on the internet (e.g. the thou…

Is there a way to see if any CA has issued a cert for a site? If all CAs posted the certs they sign to some database, then there could be services that alert you and you'd know right away and raise an alarm. If such a system doesn't exist, why not?

Re: For DNSSEC

#29
post #28
post #16

With the current CA system, you have to worry about far more than just the CAs. An attacker just needs to MITM the connection between the target website and a CA of his choosing, and the CA will give the attacker domain-validated certificates for the target website. So the current SSL in browsers can be compromised not just by the 600+ CAs, but also by anyone who can launch MITM attacks on the internet (e.g. the thou…

Is there a way to see if any CA has issued a cert for a site? If all CAs posted the certs they sign to some database, then there could be services that alert you and you'd know right away and raise an alarm. If such a system doesn't exist, why not?

Certificate Transparency (http://www.certificate-transparency.org) is a Google initiative working on just that. It's already required for EV certs in Chrome.

Re: For DNSSEC

#30

Earlier quoted context omitted.

What do you mean?

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.

Post reply on HN