For DNSSEC
blog.easydns.org
blog.easydns.org
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.
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 thousands of ISPs who can publish BGP routes).
For email-based domain validation, the attacker doesn't even need MITM capabilities -- catching the domain validation email in passive bulk data collection is sufficient. The NSA can trivially get valid certificates for arbitrary domains even without the cooperation of any CA! And if the attack on the target website is discovered, it would look like $RANDOM_CA is to blame, even when the CA did nothing wrong (unless you consider the whole idea of domain-validated certificates to be wrong).
DNSSEC+DANE has the potential to be much much more secure than the status quo. The problem is that no one wants to be the first to implement client-side DNSSEC validation and get blamed for failing to connect to incorrectly configured domains.
Does https://pki.google.com/ do that?
As with all browsers, only a subset of CAs are trusted to provide EV certs in the first place, regardless of whether they include the EV bits in the certificate. And this policy only applies to EV certs, not to all certs by an EV-capable CA.
Oddly enough I noticed the other day that certificate-transparency.org isn't even accessible over https.
(Eventually this should go away because a compromised CA key can obviously just lie about the time, but this is just a migration step.)
The current Internet-Draft for RFC 6962bis allows them to register this in CT logs as "?.uber.com", which is enough for Uber's sysadmins to raise an alarm if something matching that pattern was issued without their knowledge.
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08#...
"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
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.
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.
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".
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.
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.
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 intersection of security and cryptography: Key Management. I conclude by pointing out that DNSSEC does indeed contain a coherent, viable approach to key management across organizational boundaries, while this talk — alas — does not."
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.
Do you rely almost exclusively on the first connection to a server being correct? Apparently. Does SSH? No.
Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data, so that it can be served securely by organizations that can't afford HSMs. And it should be used in a similar way to DANE -- for bootstrapping other protocols in a general way.
~~Huh? That is what a PKI consists of....~~
> Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data
~~DNSSEC was, from the outset, designed to support offline signing.~~
Update: Whoops, I misread what you wrote! : )
How do you sign a key/value data set with a certificate from Verisign? Are there tools that can automatically follow this delegation?
In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later.
I can't add a signed value for __custom_protocol__._wellknown.me.com that uses the existing x509 infrastructure. If I add another server, I can't delegate to it.
> DNSSEC was, from the outset, designed to support offline signing.
Yes... that's what I said. The replacement should support it, too.
If your domain root is signed by Verisign, you get your domain key signed through your register. The actual procedure varies with the register, from impossible to fully automated. DNS is exactly a key/value dataset.
I just don't understand the point of your other questions:
>Are there tools that can automatically follow this delegation?
Just list the domain. You'll see all delegations there.
> In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later.
> I can't add a signed value for __custom_protocol__._wellknown.me.com that uses the existing x509 infrastructure. If I add another server, I can't delegate to it.
Are you arguing that the specific certificates are better? Why?
We seem to be having a communication issue.
From [1]: "Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore a large number of CAs exist on the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, as in common business practice."
With DNSSEC this is not a problem. Once I have a DS key pointing to my zone, I can delegate as much as I want. This allows a great deal of flexibility, as I've already mentioned.
[1]: https://en.wikipedia.org/wiki/X.509#Problems_with_certificat...
The delegation implemented in DNSSEC is a good thing. I didn't think about how that feature would quite reasonably be lumped in with "PKI".
Oops.
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.
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 thousand to hundreds of thousands of users Lavabit-like service, too.
(I'm not sure if this is what was being asked, but I'm curious about the answer to that, either way.)
(Phreebird is an online signer, but I don't see why an offline signer couldn't generate these proofs.)
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.
(And indeed, it cannot be done offline - although doing much narrower NSEC/NSEC3 ranges than 'normal' could be done offline).
Doesn't change the design problems. Just tries to hide them behind half-truths and "but there's nothing better..."
Having a central online signing server is bad for availability, as DNS down time is really not acceptable.
That basically only leaves offline signing.
I'd it being the preferred option is strong evidence that the extra complexity is worth it.