7 ms·
For DNSSEC
- yuhong 11y agoPersonally I think a new DNSSEC2 based on for example online signing might be a good idea.
- indolering 11y agoThere is nothing stopping you from doing online signing with DNSSEC. FWIW, DNSSEC is on it's third major iteration, 2/3rds of the TLDs have deployed it, and major DNS service providers are getting into the act.
- marcosdumay 11y agoYou can even avoid domain enumeration by doing online signing with DNSSEC. It's just that people still prefer the offline option.
- yuhong 11y agoAnd the offline signing option adds complexity to the protocol.
- indolering 11y agoSo you are arguing to remove the offline signing capabilities?
- yuhong 11y agoYes.
- indolering 11y agoThat would force companies to either own all of the front-end server farms or store their keys on machines in untrustworthy environments.
- tptacek 11y agoYes: a choice between two very unattractive options. Isn't DNSSEC great?
- indolering 11y agoUh? You can run everything in offline mode, unless you really care about trivial zone enumeration.
- yuhong 11y agoI am not talking about the current DNSSEC, of course.
- Habbie 11y agoI.E. the way SSL/TLS is run today.
- marcosdumay 11y agoOk, 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.
- StuntPope 11y agoWhat do you mean?
- yuhong 11y agoDNSSEC has several problems some of which is in the design, as tptacek likes to mention.
- StuntPope 11y agoBut what do you mean by "online signing" ?
- yuhong 11y agoOne of the problems is that it exposed DNS zone information, and one of the reason it did that was it was designed to require signing only once and after that the private key didn't have to be used again until the zone info changes.
- indolering 11y agoAre you talking about zone enumeration? That's covered in the article.
- geofft 11y agoCan you provide an NSEC white-lie response to an arbitrary query without an online key? (I'm not sure if this is what was being asked, but I'm curious about the answer to that, either way.)
- yuhong 11y agoDon't think so.
- indolering 11y ago
- oconnore 11y agoDNSSEC got PKI wrong, but what it got right was building authentication (DANE, etc) on a standard protocol (DNS) for exchanging key/value data. 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.
- indolering 11y ago> DNSSEC got PKI wrong, but what it got right was building authentication (DANE, etc) on a standard protocol (DNS) for exchanging key/value data. ~~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! : )
- oconnore 11y ago> Huh? That is what a PKI consists of.... 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.
- marcosdumay 11y ago> How do you sign a key/value data set with a certificate from Verisign? 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?
- ynik 11y agoWith 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 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.
- deleted 11y ago[deleted]
- ikeboy 11y agoIs 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?
- realityking 11y agoCertificate Transparency (http://www.certificate-transparency.org http://www.certificate-transparency.org) is a Google initiative working on just that. It's already required for EV certs in Chrome.
- ikeboy 11y agoHave any CAs publically committed to submit all their generated certs to that? Does https://pki.google.com/ https://pki.google.com/ do that?
- mtgx 11y agoWhat 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 thousand to hundreds of thousands of users Lavabit-like service, too.
- indolering 11y agoThey are moving the ECC for DNS record signing, not HTTPS certificates.
- doomrobo 11y agoWhere 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.
- akerl_ 11y agoSo 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.
- indolering 11y agoThe 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.
- cbsmith 11y ago> And even if you choose a decentralized DNS solution, you still need DNSSEC. 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.
- indolering 11y agoAs covered in TFA, DNSCurve provides encryption between a DNS resolver and the client. It doesn't allow domain owners to sign their records. Dan Kaminsky did a good job taking DNSCurve apart back in 2011: http://dankaminsky.com/2011/01/05/djb-ccc/ 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."
- sarciszewski 11y agoThis 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
- indolering 11y ago> "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.
- sarciszewski 11y agoGood, come back when it's standardized. Until then, stamps [REJECTED] on the DNSSEC folder death to 90's crypto
- geofft 11y agoI thought part of successfully killing off '90s crypto was deploying useful, obviously-correct systems without waiting for standards committees to bikeshed them to death (cf. CFRG).
- sarciszewski 11y agoSorry what were you saying? I couldn't hear you over the bitter arguments about endian-ness.
- indolering 11y ago> 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.
- fensipens 11y agoSSH 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.
- geofft 11y agoIn practice, I have few ways of verifying SSH fingerprints that don't involve trusting the SSL PKI.
- tptacek 11y agoThe 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 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.
- yuhong 11y agoAlso see my other HN thread on how to fix it.
- indolering 11y agoI tried to address all the major points in your FAQ and Adam Langley's follow-on blogpost as well, but I will take another crack at it.
- deleted 11y ago[deleted]
- indolering 11y agoHey, I mistook the QA for your FAQ post, my overall thesis hasn't changed but I will follow up on the new info in your QA post : )