4 ms·

These are just the same old arguments all over again. 1. DNSSEC is unnecessary, we have SSL. Do you really want to argue that the CA PKI infrastructure is wor

by xorcist 12y ago

These are just the same old arguments all over again. 1. DNSSEC is unnecessary, we have SSL. Do you really want to argue that the CA PKI infrastructure is working? Placing your trust in your top domain solves 99.5% of the problem, roughly (considering there is about 500 CAs that you trust right now, that is not a made up number). 2. DNSSEC is a government-controlled PKI. No, it's not. It is ICANN-controlled, which is under government mandate but not government control. You already trust ICANN for the root zone, and they have so far stayed out of politics, and has so far never meddled with domains even when the US administration wants them shut down. Because if they did, the Internet would route around them in a heartbeat. This is actually one thing that DNSSEC did absolutely correct. If you want a cryptographic assurance that a domain belongs to an owner, who better to make the assertion than the TLD responsible for delegating it? Sure, if you get a Libyan domain, you have to trust the Libyan TLD to sign it. But they are already trusted to delegate it! They run the whois. If they decide to transfer the ownership to Ghaddafi himself, there is absolutely nothing you can do about it. If this is a problem for you, don't get a Libyan domain name. 3. DNSSEC is insecure. It's ugly, but it's not insecure in any practical way. It could be a lot more modern, but it is in no way worse than SSL (see 1 above). 4. DNSSEC is expensive. It is already deployed. You are already paying the price for this, whatever it was. 5. DNSSEC is hard. It adds complexity to your operations, but your tools already supports it and it's included in courses already. No competing standard is. 6. DNSSEC makes for DDoS. That wasn't actually included in the list, but this one is true. DNS is a DDoS vector, and DNSSEC strengthens it. That should be addressed. Better deployment of filters would do much to improve the situation. 7. DNSSEC allows for enumration of zones. Also not included in the list. Yes, this is a real issue you need to be aware of. Don't store private data in public zones. Use split zones for this. All technical decisions is a matter of pros and cons. Pro is that it builds on a proven infrastructure and is already deployed in most of the world. You could absolutely build a modern standard, but these things take at least ten years to roll out. Start today and build the successor to DNSSEC! But remember that DNSSEC did get a few important things right: Assurance follows delegation. Your DNS operator does not have your key. It protects against negative answers. Make sure your successor inherits those.

codexon 12y ago
> Better deployment of filters would do much to improve the situation. No, it wouldn't. People have been calling for an to end spoofing for 15 years with virtually 0 progress. Filters don't help in volumetric attacks.
tptacek 12y ago
First, I'd be a little happier if you didn't misquote me for the convenience of your comment. These weren't my subheds. You've rewritten some of them, condensed others, added one, and misread another, which lead you to suggest that I hadn't "allowed for enumeration of zones" when in fact there's a whole subhed dedicated to it. You could just clarify at the top of your comments that your numbered list is your own, not mine. I'd then strike this part of my comment. Now then: 1. I do not argue that the CA PKI infrastructure is working. In fact, I state explicitly that it is not. The problem is that DANE's replacement for the TLS PKI is controlled by world governments. At a broader level, the problem is that centralized PKIs don't work against nation-state adversaries. The solution for the TLS CA problem is (a) a race to the bottom for CA pricing, led hopefully by EFF, (b) widespread deployment of public key pinning, which serves both to thwart CA attacks and to create a global surveillance system against them, and (c) the eventual deployment of alternate opt-in TLS CA hierarchies, such that users could for instance subscribe to a hypothetical EFF CA hierarchy. DNSSEC accomplishes none of this. 2. Yes, DNSSEC is a government-controlled PKI. Your whole argument here is that if governments abused it, the Internet would "route around it". You can't make that argument without conceding my point. 3. I didn't write "DNSSEC is insecure" (though I think it is). I wrote that it's cryptographically weak, which it is: it's PKCS1v15 RSA-1024. Crawl signatures back to the roots: you'll see RSA-1024 all the way at the top of the hierarchy. TLS has already deployed forward-secure ECC cryptography and will by the middle of this year see widespread deployment of Curve25519 ECDH and Ed25519 deterministic signatures. DNSSEC simply will not: it will be RSA-1024 for the foreseeable future. 4. "DNSSEC is expensive" is not a subhed in my post. "DNSSEC is expensive to adopt" was, and it is: virtually no networking software currently handles soft failures from lookups, which are a universal shared experience among HTTPS users, and will occur just as frequently with DNSSEC (should it ever be deployed). "DNSSEC is expensive to deploy" is another point I made, which is also true: of the top 50 Alexa sites, why not go look how many are DNSSEC-signed? 5. "DNSSEC is hard" isn't something I wrote at all, so I don't know how to respond to it. 6. "DNSSEC makes for DDoS" is something I think is probably true, but also an argument I wasn't willing to go to bat for, because amplification attacks using ANY queries against normal DNS also work. But sure, if you want to add fuel to the fire. 7. "DNSSEC allows for enumeration of zones" is captured under "DNSSEC is unsafe" in my post. If you answer to this is "don't use DNSSEC for important zones", then we agree, modulo that I think you shouldn't use it at all.

by xorcist 12y ago

codexon 12y ago

> Better deployment of filters would do much to improve the situation. No, it wouldn't. People have been calling for an to end spoofing for 15 years with virtually 0 progress. Filters don't help in volumetric attacks.

tptacek 12y ago

First, I'd be a little happier if you didn't misquote me for the convenience of your comment. These weren't my subheds. You've rewritten some of them, condensed others, added one, and misread another, which lead you to suggest that I hadn't "allowed for enumeration of zones" when in fact there's a whole subhed dedicated to it. You could just clarify at the top of your comments that your numbered list is your own, not mine. I'd then strike this part of my comment. Now then: 1. I do not argue that the CA PKI infrastructure is working. In fact, I state explicitly that it is not. The problem is that DANE's replacement for the TLS PKI is controlled by world governments. At a broader level, the problem is that centralized PKIs don't work against nation-state adversaries. The solution for the TLS CA problem is (a) a race to the bottom for CA pricing, led hopefully by EFF, (b) widespread deployment of public key pinning, which serves both to thwart CA attacks and to create a global surveillance system against them, and (c) the eventual deployment of alternate opt-in TLS CA hierarchies, such that users could for instance subscribe to a hypothetical EFF CA hierarchy. DNSSEC accomplishes none of this. 2. Yes, DNSSEC is a government-controlled PKI. Your whole argument here is that if governments abused it, the Internet would "route around it". You can't make that argument without conceding my point. 3. I didn't write "DNSSEC is insecure" (though I think it is). I wrote that it's cryptographically weak, which it is: it's PKCS1v15 RSA-1024. Crawl signatures back to the roots: you'll see RSA-1024 all the way at the top of the hierarchy. TLS has already deployed forward-secure ECC cryptography and will by the middle of this year see widespread deployment of Curve25519 ECDH and Ed25519 deterministic signatures. DNSSEC simply will not: it will be RSA-1024 for the foreseeable future. 4. "DNSSEC is expensive" is not a subhed in my post. "DNSSEC is expensive to adopt" was, and it is: virtually no networking software currently handles soft failures from lookups, which are a universal shared experience among HTTPS users, and will occur just as frequently with DNSSEC (should it ever be deployed). "DNSSEC is expensive to deploy" is another point I made, which is also true: of the top 50 Alexa sites, why not go look how many are DNSSEC-signed? 5. "DNSSEC is hard" isn't something I wrote at all, so I don't know how to respond to it. 6. "DNSSEC makes for DDoS" is something I think is probably true, but also an argument I wasn't willing to go to bat for, because amplification attacks using ANY queries against normal DNS also work. But sure, if you want to add fuel to the fire. 7. "DNSSEC allows for enumeration of zones" is captured under "DNSSEC is unsafe" in my post. If you answer to this is "don't use DNSSEC for important zones", then we agree, modulo that I think you shouldn't use it at all.