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.
For DNSSEC
51–60 of 81 posts
Re: For DNSSEC
#52Re: For DNSSEC
#53Re: For DNSSEC
#54Earlier 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.
I'd it being the preferred option is strong evidence that the extra complexity is worth it.
Re: For DNSSEC
#55SSH 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.
Re: For DNSSEC
#56Earlier 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'm sorry you're so laser focused on your own writing, but the DNSSEC debate is bigger than you.
Re: For DNSSEC
#57http://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
#58With 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…
Re: For DNSSEC
#59This 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.
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
#60Earlier 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.