Fedora 21 To Have DNSSEC Validation Enabled By Default(internetsociety.org)
internetsociety.org
Fedora 21 To Have DNSSEC Validation Enabled By Default
http://www.internetsociety.org/deploy360/blog/2014/05/fedora-21-to-have-dnssec-validation-enabled-by-default/
3 comments
I'm not a big fan of Fedora's toxic adoption of shitty technology, but it would be unfair to lay a lot of blame on Fedora for this. You aren't forced to use DNSSEC, it's just going to use DNSSEC if a domain is set up to use it. The people to blame for the adoption of DNSSEC are the asshats that try to push it as a solution for all our problems, or mandate it across organizations.
Where Fedora does have blame is the extensive weasel language they use to pretend DNSSEC is the only solution for providing "trust". DNSCurve doesn't exist according to Fedora.
Where Fedora does have blame is the extensive weasel language they use to pretend DNSSEC is the only solution for providing "trust". DNSCurve doesn't exist according to Fedora.
I'm not sure I follow your comment. How do you see DNSSEC as signing anything over to the government? The point of DNSSEC was/is solely to prevent cache poisoning by "chaining" answers from root to auth with signatures. It only proves the answer provided is correct by DNS means. It does not attempt to guarantee authenticity of a destination.
Also, DNSSEC supports multiple algorithms, including ECDSA, though RSA is the most widely used at the moment.
Is it perfect? Of course not. But it's out there now, and it works for what it was designed for.
The roots of the DNS tree are controlled by world governments. The roots of the DNSSEC PKI are the roots of the DNS tree. And, no, the point of DNSSEC isn't solely to prevent cache poisoning; in fact, the motivating use case for DNSSEC in 2014 is DANE, which replaces the CA hierarchy with DNSSEC.
Assuming that the governments really could just manipulate the root at will(every root, which is many machines, remember)... the only thing they could do is break DNSSEC. The DS hints would not match the KSK of the tld zone otherwise...unless of course every government in the world was in on it together...illuminati, free-masons, oh the Rothchilds are in on it too I think.
Seriously, this is a borderline absurd statement. The only way to manipulate the root in a way that allows DNSSEC to work otherwise is to redirect all traffic for every tld to new government owned servers with a matching KSK in place. Not very realistic.
It would be useful to put forward a single credible scenario where "world" governments can use the DNS root private key in any fashion without detection. It is impossible to have a reasoned debate about DNSSEC with straw men like this.
Are you familiar with the CAP theorem, or do you believe that it's impossible for one query to a globally distributed database to get a different answer for the same question than every other query?
Every time someone tells me that DNSSEC tampering would be "detectible", it always seems premised on the idea that everyone sees the same data. Of course, attackers will isolate their targets and attack them surgically.
What's worse, none of what you're talking about is cryptographic. This is protection by dint of being lucky enough to be on the right part of the network to be hard to attack. No sound cryptosystem works like that.
Every time someone tells me that DNSSEC tampering would be "detectible", it always seems premised on the idea that everyone sees the same data. Of course, attackers will isolate their targets and attack them surgically.
What's worse, none of what you're talking about is cryptographic. This is protection by dint of being lucky enough to be on the right part of the network to be hard to attack. No sound cryptosystem works like that.
I thought your first comment was just grumbling, but this comment
suggests some misunderstanding.
The root zsk is split over a group (Shamir share) held by mostly non-US key holders. (One from the US is Dan Kaminsky, whose work and my user name has special relevancy for you. You'd agree he's not part of the US government.)
I believe all the key holders are trustworthy, and if any were not, you'd need a majority (5 of the 7) to subvert the zsk. So an xkcd-wrench-style attack on the key by governments would require implausible circumstances.
The key ceremony is video taped and can be watched:
You can read more about the DNSSEC root zone key management process and people (non-governmental) online. Here are informal press stories with the usual set of mistakes and minor errors:
The root zsk is split over a group (Shamir share) held by mostly non-US key holders. (One from the US is Dan Kaminsky, whose work and my user name has special relevancy for you. You'd agree he's not part of the US government.)
I believe all the key holders are trustworthy, and if any were not, you'd need a majority (5 of the 7) to subvert the zsk. So an xkcd-wrench-style attack on the key by governments would require implausible circumstances.
The key ceremony is video taped and can be watched:
https://www.youtube.com/watch?v=b9j-sfP9GUU
You can read more about the DNSSEC root zone key management process and people (non-governmental) online. Here are informal press stories with the usual set of mistakes and minor errors:
http://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwide-internet-security-web
https://www.schneier.com/blog/archives/2010/07/dnssec_root_key.html
http://www.root-dnssec.org/
It would be good if we actually had CA hierarchy, I wouldn't call the current CA system a hierarchy[]: any Root CA can issue a valid certificate for any domain, all Root CAs are equal in power, a compromise of any* of them allows valid certificates to be issued for anything. Sure there are protections like certificate pinning, etc. but still the more Root CAs you have, the higher the risks.
I think that reducing the amount of organizations controlling your particular branch of DNS is good. You may trust the US CA issue cert for US sites, those are more or less under their control anyway, but you probably don't want to trust them for .eu sites. Or why should I trust the Chinese CA for anything but chinese sites?
And more to the point: why should a CA be allowed to issue a cert for a site that already has a cert issues by another CA.
DNSSEC is hierarchic, there is one key for example.com. in the parent zone com., if someone else wants to put a key for example.com. into com. they'll have to replace it. Presumable the owner of example.com. would monitor its own record in com. and notice tampering. You can't easily have random CA issuing certs for your sites without being detected.
Of course having only a single entity is not good again, because then you introduce a single point of failure.
[*] well of course at the X509 level you have subordinate CAs, and a hierarchy, but it is in no way tied to DNS.
I think that reducing the amount of organizations controlling your particular branch of DNS is good. You may trust the US CA issue cert for US sites, those are more or less under their control anyway, but you probably don't want to trust them for .eu sites. Or why should I trust the Chinese CA for anything but chinese sites?
And more to the point: why should a CA be allowed to issue a cert for a site that already has a cert issues by another CA.
DNSSEC is hierarchic, there is one key for example.com. in the parent zone com., if someone else wants to put a key for example.com. into com. they'll have to replace it. Presumable the owner of example.com. would monitor its own record in com. and notice tampering. You can't easily have random CA issuing certs for your sites without being detected.
Of course having only a single entity is not good again, because then you introduce a single point of failure.
[*] well of course at the X509 level you have subordinate CAs, and a hierarchy, but it is in no way tied to DNS.
I'm not sure I see how the roots of the DNS tree are controlled by world governments. Here are the root servers: http://www.root-servers.org/ They are controlled by a wide range of organizations scattered all over the world.
The data in root "." is controlled by ICANN, a US corporation. The data in the most important gTLD, .com, is run by Verisign on contract with the US Chamber of Commerce. The ccTLDs (.fr, .tw, etc.) are controlled by world governments.
Sure, the root and major TLDs are anycasted across the globe, but the "wide range" of organizations are just mirroring content that is in one way or another controlled by world governments, and given (for example) ICE domain seizures, it would be prudent not to over-rely on DNS. Personally I support DNSCurve as a means to secure DNS, not to replace security we already have elsewhere.
Sure, the root and major TLDs are anycasted across the globe, but the "wide range" of organizations are just mirroring content that is in one way or another controlled by world governments, and given (for example) ICE domain seizures, it would be prudent not to over-rely on DNS. Personally I support DNSCurve as a means to secure DNS, not to replace security we already have elsewhere.
I guess we'll have to agree to disagree. I've worked with the ICANN DNS people enough and am aware of their practices enough (ex. https://www.iana.org/dnssec/icann-dps.txt ) that I don't see how the root zone could be compromised without people knowing.
Separately, DNScurve is interesting, but really solves a different problem than DNSSEC. I find this a useful comparison: http://security.stackexchange.com/questions/45770/if-dnssec-...
Separately, DNScurve is interesting, but really solves a different problem than DNSSEC. I find this a useful comparison: http://security.stackexchange.com/questions/45770/if-dnssec-...
By definition a tree has a single root. Please specify what you mean be "roots".
The private key of the DNS root was split in seven parts held by seven people [1]. It is stored in two HSMs, one on the east coast of the United States, one on the west coast. Could the NSA or some other agency have gotten hold of the private key? Probably. But spinning that as "the DNSSEC root is controlled by the governments" is FUD.
[1] http://venturebeat.com/2010/07/28/seven-security-experts-get...
The private key of the DNS root was split in seven parts held by seven people [1]. It is stored in two HSMs, one on the east coast of the United States, one on the west coast. Could the NSA or some other agency have gotten hold of the private key? Probably. But spinning that as "the DNSSEC root is controlled by the governments" is FUD.
[1] http://venturebeat.com/2010/07/28/seven-security-experts-get...
When DNSSEC says "bit.ly" is correct and valid, what organizations or entities could have messed with the results?
The concern that the Lybian TLD registry might fake NS and/or DS records of 2LDs applies equally to unsigned and signed zones. So if that is a concern, why use an untrusted TLD, or why use DNS at all?
If you do not trust the Lybian TLD, configure a negative trust anchor for that TLD in your resolver.
Alternatively, if you want to pin that TLD to a particular KSK, configure that KSK as a (positive) trust anchor in your resolver.
If you do not trust the IANA at all, disable the IANA root in your resolver and add trust anchors for the domains you trust. Use lookaside validation if you find that too cumbersome and want to let others do that work for you.
If you do not trust the Lybian TLD, configure a negative trust anchor for that TLD in your resolver.
Alternatively, if you want to pin that TLD to a particular KSK, configure that KSK as a (positive) trust anchor in your resolver.
If you do not trust the IANA at all, disable the IANA root in your resolver and add trust anchors for the domains you trust. Use lookaside validation if you find that too cumbersome and want to let others do that work for you.
Why did you pick an example that does not use DNSSEC? It seems your thesis would be a lot stronger if you used a top and second level domain that actually implemented DNSSEC:
root@fw:~# unbound-host -t A -v bit.ly
bit.ly has address 69.58.188.39 (insecure)
bit.ly has address 69.58.188.40 (insecure)
I can't tell if you are trying to deliberately miss the point.
If those in charge of ly decided to implement dnssec, then who is in charge with respect to GP.
If those in charge of ly decided to implement dnssec, then who is in charge with respect to GP.
> Why did you pick an example that does not use DNSSEC?
Because I'm trying to illustrate how much additional security you might or might not get if you added DNSSEC, especially with regards to government entities.
Because I'm trying to illustrate how much additional security you might or might not get if you added DNSSEC, especially with regards to government entities.
The answer is "N/A." The .ly tld is not signed so DNSSEC could never attest to the authenticity of the A record for bit.ly.
In order for this to be a useful exercise you should structure the question in such a way that there is as much potential for government interference as possible. (Unless you are looking for a specific answer and you are trying to lead the respondent.) Government interference with DNSSEC is not limited to the `.` zone. Or put another way, DNSSEC's attack surface area is not limited to the sacred KSK.
In order for this to be a useful exercise you should structure the question in such a way that there is as much potential for government interference as possible. (Unless you are looking for a specific answer and you are trying to lead the respondent.) Government interference with DNSSEC is not limited to the `.` zone. Or put another way, DNSSEC's attack surface area is not limited to the sacred KSK.
If bit.ly implemented DNSSEC exactly to spec, and it appears clean to a user, who could be an attacker and in what way?
Anyone can be an attacker that can exert influence (legal/kinetic/digital) over:
Here: .
Here: .ly.
Here: .bit.ly.
Here: . # G/K/D same as bit.ly
Here: .org. # K/D same as bit.ly
Here: .freebsd.org. # K/D same as bit.ly > Sign it over to the government
[^1]: https://news.ycombinator.com/item?id=7615911
One difference between the CA system and DNSSEC w/r/t/ government dependence is that DNSSEC's dependence on government fiat is explicit and de jure, and the CA system's is implied and de facto.
Another difference between CA and DNSSEC government dependence is that DNSSEC is, as I said, baked into the core of the Internet; it sets policy for name resolution. It's difficult to override decisions made by DNS/DNSSEC. The same isn't true of the CA system; for instance, everyone using Chrome and Firefox is routinely overriding the CA system when they use Google Mail.
No, it's not simply a rhetorical device.
Another difference between CA and DNSSEC government dependence is that DNSSEC is, as I said, baked into the core of the Internet; it sets policy for name resolution. It's difficult to override decisions made by DNS/DNSSEC. The same isn't true of the CA system; for instance, everyone using Chrome and Firefox is routinely overriding the CA system when they use Google Mail.
No, it's not simply a rhetorical device.
DNSSEC's explicit reliance on government is dependent on ICANN's MoU. The role of government is a lot different when using ISC's DLV. Is pinning gmail's cert any different than using a google supplied DLV key?
DLV: "Screw ICANN, I'm going to build my own DNS, with blackjack and hookers."
I know it sounds a little goofy and I am not trying to be difficult just to be a dick, it was a genuine/good-faith response. Is it really that different than:
Cert Pinning: "Screw the CA cabal, I'm going to build my own PKI, with blackjack and hookers."
Certificate pinning only works when I interact with gmail via FF/Chromium on port 443. When postfix connects to gmail over 25/465/587 we fall back to the CA-cabal if (a big if) postfix is configured to verify certificates.
We can take the madness full circle:
DLV+DANE: "Screw pinning certs in the browser, I'm going to pin all the things, with blackjack and hookers."
Cert Pinning: "Screw the CA cabal, I'm going to build my own PKI, with blackjack and hookers."
Certificate pinning only works when I interact with gmail via FF/Chromium on port 443. When postfix connects to gmail over 25/465/587 we fall back to the CA-cabal if (a big if) postfix is configured to verify certificates.
We can take the madness full circle:
DLV+DANE: "Screw pinning certs in the browser, I'm going to pin all the things, with blackjack and hookers."
You have me at a disadvantage as I had a wisdom tooth pulled just an hour or two ago, but I'll point out that having multiple different CA policies is actually not that big a deal (witness that we do that today with pinning), whereas running multiple DNS lookaside policies is an operations clusterfuck.
You have me at a disadvantage because you probably had more wisdom in the one tooth about these things than I do in total;) I think the reason that cert pinning is "not that big of a deal" is that it only works for a small number of organizations, on a small set of applications, for one of 65,535 ports. The cert pinning system does not work for billybobsblog.com, is not implemented in wget/curl/ruby/python and does not protect my gmail data over 25/143/465/587/993. Yes, "pinning all the things" with DANE+DLV would be a giant clusterfuck but that is simply because it is cert pinning writ large. Fixing the damn is always a clusterfuck compared to sticking a thumb in the most conspicuous leak and calling it a day.
I don't want to drag this on any longer than needed.[^1] I hope that the dental recuperation is uneventful. If it is any consolation I got a chuckle imagining C.J. Craig from the West Wing reading your messages right after her "woot can-owl surge-ah-wee."
[^1]: The next time DNSSEC comes up (and it will) I would like to get your take on how you think the problems with names/certificates compare to those described in "Reflections on Trusting Trust." It seems like trusting everything down to the bare metal is only a tad more Sisyphean.
I don't want to drag this on any longer than needed.[^1] I hope that the dental recuperation is uneventful. If it is any consolation I got a chuckle imagining C.J. Craig from the West Wing reading your messages right after her "woot can-owl surge-ah-wee."
[^1]: The next time DNSSEC comes up (and it will) I would like to get your take on how you think the problems with names/certificates compare to those described in "Reflections on Trusting Trust." It seems like trusting everything down to the bare metal is only a tad more Sisyphean.
Some previous discussions
https://news.ycombinator.com/item?id=2939002 http://tawqer.com/comment/12538720#.U2Ql4IL7HIE https://news.ycombinator.com/item?id=1234721
Djb on dnscurve, a better way: http://marc.info/?l=djbdns&m=129434351607605&w=2 https://news.ycombinator.com/item?id=2078475
and others.
https://news.ycombinator.com/item?id=2939002 http://tawqer.com/comment/12538720#.U2Ql4IL7HIE https://news.ycombinator.com/item?id=1234721
Djb on dnscurve, a better way: http://marc.info/?l=djbdns&m=129434351607605&w=2 https://news.ycombinator.com/item?id=2078475
and others.
It is a little difficult to figure out what you are trying to say when the bulk of your comment is "invoke other people's words." Initially it seems that you are a proponent of DNSCurve but you directed my attention to a link that highlights a fault of DNSSEC and DNSCurve. You linked to a page[^1] pointing out that:
[^1]: I recognize the author, but that is irrelevant. In fact I am not sure that the author would want to bring up this problem in the context of this discussion.
[^2]: High-speed cryptography and DNSCurve, pg 26-27. http://cr.yp.to/talks/2009.06.27/slides.pdf
> Libya(!) controls .ly. If DANE had been successful a few years
> ago, Ghaddafi's government would have controlled bit.ly's certs.
> How does DNSCurve client retrieve server’s public key?
> DNS architecture: DNS client learns IP address of .bit.ly DNS
> server from .ly DNS server.
> The .ly server says: “The bit.ly DNS server is named petard and
> has IP address 666.1.0.3.”
> The name petard was selected by the bit.ly admin and given to .ly.
> To announce his DNSCurve server’s public key, the bit.ly admin
> changes the name petard to an encoding of the public key.
> The DNSCurve client sees the public key, begins cryptographically
> protecting communication with that server.
[^1]: I recognize the author, but that is irrelevant. In fact I am not sure that the author would want to bring up this problem in the context of this discussion.
[^2]: High-speed cryptography and DNSCurve, pg 26-27. http://cr.yp.to/talks/2009.06.27/slides.pdf
Compared to the U.S. Gaddafi was a saint. I know you yanks have been brainwashed, but he was nowhere near as bad as your demagogue policitians and media would have you believe. Likewise for the other few dozen world leaders and revolutionaries the U.S. have murdered.
You think a silly, hipster domain hack is more important than countries having control over their own national TLDs?
Well, despite its imperfections, how does DNSSEC worsen security compared to regular DNS? Besides, it's not like the use of DNSSEC prevent you from continuing to also rely on additional measures; such as good old fashions CAs, or something better.
Well, only ICANN being able to issue fake signatures is much better than hundreds of random organizations around the world being able to do so.
I remember seeing you mention a draft of an DNSSEC "jeremiad", but I never saw the final product. A quick Google search doesn't find it. Has it been made available to a wider audience yet?
No, not yet. It's 7000 words long (I cover a lot of detail, including stuff from pre-DNSSECter and pre-DNSSECbis, and a lot of it doesn't really need to be there). I'll post it someday soonish.
The NSA uses Fedora as their standard laptop distro. There will definitely be influence on Fedora from that direction.
Most modern crypto is all but banned by Fedora's (really Redhat's) packaging policies. They only recently agreed to enable ECDSA in OpenSSL, and even then, only with NIST curves. There's a lot of other very shady overrides and limitations they impose on crytpo packages too, and any questions about them are invariably met with a chorus of "we are not at liberty to comment" from some lawyer type. NSA clearly have them by the balls.
More details please
https://bugzilla.redhat.com/show_bug.cgi?id=319901 is an interesting thread. And https://bugzilla.redhat.com/show_bug.cgi?id=1021898 .
My take is that RH is more afraid from patent trolling than some kind of shady government deal.
(edit: expanding why it's more against patent trolling: see their "Open Source Assurance" program: http://www.redhat.com/rhel/details/assurance/ , they provide indemnification, thus their legal department seems to be more on the cautious side)
My take is that RH is more afraid from patent trolling than some kind of shady government deal.
(edit: expanding why it's more against patent trolling: see their "Open Source Assurance" program: http://www.redhat.com/rhel/details/assurance/ , they provide indemnification, thus their legal department seems to be more on the cautious side)
Wow, feels like it's the 90s again with PGP and 40bit export browsers!
FreeBSD 10 ships with Unbound in the base system too... Sadly, it's not enabled by default, but a lot of people enable it for performance (caching) and they get security for free.
# sysrc local_unbound_enable=YES # service local_unbound start
# sysrc local_unbound_enable=YES # service local_unbound start
CeroWrt picked up the DNSSEC-enabled version of dnsmasq as soon as it was released, and it's been a huge hassle even among that small and technically capable userbase. Fedora has done more to try to make it usable (detecting captive portals, etc.), but there are simply too many broken networks and DNS servers out there for DNSSEC to be used to do anything more strict than putting a red flag in the browser's URL bar.
Thanks, Fedora.