Live data from Hacker News

For DNSSEC

blog.easydns.org

51–60 of 81 posts

Re: For DNSSEC

#51
post #31

Earlier quoted context omitted.

You can even avoid domain enumeration by doing online signing with DNSSEC. It's just that people still prefer the offline option.

And the offline signing option adds complexity to the protocol.

So you are arguing to remove the offline signing capabilities?

Re: For DNSSEC

#54
post #31

Earlier quoted context omitted.

You can even avoid domain enumeration by doing online signing with DNSSEC. It's just that people still prefer the offline option.

And the offline signing option adds complexity to the protocol.

Ok, my point about people preferring the offline option wasn't criticism.

I'd it being the preferred option is strong evidence that the extra complexity is worth it.

Re: For DNSSEC

#55

SSH relies almost exclusively on the first connection to a server being correct and an attacker being unable to perpetuate a MITM attack against a given host. Do you rely almost exclusively on the first connection to a server being correct? Apparently. Does SSH? No.

In practice, I have few ways of verifying SSH fingerprints that don't involve trusting the SSL PKI.

Re: For DNSSEC

#56

Earlier quoted context omitted.

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

> Until then, stamps [REJECTED] on the DNSSEC folder death to 90's crypto If you read TFA you would see that we are transitioning to P-256. FWIW, ECC crypto is really slow and we will need to transition to post-quantum crypto in another 10 or 15 years.

I did the article. ECC crypto can mean ECDSA which is also flawed 90's crypto. I specifically demanded EdDSA which can more easily be implemented in a high speed and constant time.

I'm sorry you're so laser focused on your own writing, but the DNSSEC debate is bigger than you.

Re: For DNSSEC

#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 wasn't in room yet to see it, but I'm told the suggestion was met with loud, sustained laughter. DNSSEC is not going to happen. There is absolutely no chance that, in the wake of the Snowden leaks, we are going to forklift out piece of core Internet infrastructure so that the security of .COM, .CO.UK, and .NET can be permanently and irrevocably signed over to the US Government. Move on.

Re: For DNSSEC

#58
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…

That is inaccurate. Several mainstream vendors have implemented DNSSEC+DANE clientside resolvers. Chrome had one. OS X briefly had one. They were removed. DNSSEC was implemented on mainstream platforms, then taken out.

Re: For DNSSEC

#59

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.

That's an implausible claim, because even the IRTF CFRG can't standardize EdDSA.

At any rate, you can say this about literally any bad cryptosystem. "We're working on standardizing X" is just another way to say "someday maybe we'll have X".

Re: For DNSSEC

#60

Earlier quoted context omitted.

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

> Until then, stamps [REJECTED] on the DNSSEC folder death to 90's crypto If you read TFA you would see that we are transitioning to P-256. FWIW, ECC crypto is really slow and we will need to transition to post-quantum crypto in another 10 or 15 years.

"ECC crypto is really slow"? Please explain what you mean by that.
Post reply on HN