DNSSEC provides the ability for the data to be signed. The politics have come in, of course, as to who has those keys. (Now mind you, right now the US government or anyone at all can already spoof DNS responses today and interestingly enough when politics get involved, it takes longer for deployment of secure protocols to happen. whee....)
But, DNSSEC does provide every zone owner with the ability to hold a very special key so that no one else may be able to spoof stuff in their zone. Everyone would want to trust.com's key, because they're the one with all the data you need. The roots hold all the information about the TLDs, so you need to trust the roots to be able to get information about.com's servers. If someone controlled the keys for the roots and you trusted those keys (had them configured as "trust anchors") then they could spoof (signed).com record, the.com keys, etc down until example.com so you'd trust the results for example.com as secure.
But here's the secret: if you don't trust the root zone owners, then instead you can choose to set trust anchors tied to the.com key instead. You don't have to trust the root zone keys, it just makes it easier to trust only one. Paranoid people are certainly welcome to maintain a list of trusted keys for any zones they deem to be "importantly" critical. If you had a trust anchor configured for.com, then it wouldn't matter what someone with the real root zone key could do with it... You wouldn't trust the eventual results from a fake.com server a root had told you about because the cryptography would warn you that it didn't match up to your expected trust anchor for.com. I suspect that most country TLDs will already do this for their own government results (IE,.se, who already runs a secured zone, will configure the.se keys as trust anchors in its government systems).
Here's an interesting proposal for the root zone: pick two countries that hate each other and are likely to never have the same agenda. Let's call them X and Y. Give each of these countries a root key, and make the root zone use and publish results from both of them. Then, you could configure trust anchors pointing to both the X and Y keys. You could configure your system to make sure to check the DNSSEC results to validate the information up to both of these keys. That way you could ensure that since you trusted X and Y to never conspire against you together, and you would know that neither X or Y alone could have spoofed DNS data then you suddenly find yourself safe. Because of the distrust. I love the irony.
(now: you don't want to have a zillion keys for the roots... The packet sizes get larger as you add more keys, and it turns out you probably don't want more than 3 at most).
Wouldn't that preview button been a handy thing to press? Sigh...
The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie
I'm pretty sure that Paul knows about RFCs 4033-4035. I suspect you don't though.
rfcfind -n '403[345]' 4033 DNS Security Introduction and Requirements. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=52445 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Status: PROPOSED STANDARD)
4034 Resource Records for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=63879 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD)
4035 Protocol Modifications for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=130589 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD)
Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS
Do you use TLS for every web page you visit? Do you use it for all the email you deliver? Receive? FTP sites you visit?
It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures
Many tools do exist, as does hardware, to help with that process. I certainly do agree, though, that if you're trying to publish a large zone (say.com) on a very frequent basis (sub-hourly) you'll hit problems. That's always a problem with cryptographic solutions. (note: there is no requirement to pre-compute the signatures; you could compute them on the fly but that has other issues).
The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.
The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie
I'm pretty sure that Paul knows about RFCs 4033-4035. I suspect you don't though.
rfcfind -n '403[345]'
4033 DNS Security Introduction and Requirements. R. Arends, R.
Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format:
TXT=52445 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445,
RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034,
RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597,
RFC3226) (Status: PROPOSED STANDARD)
4034 Resource Records for the DNS Security Extensions. R. Arends, R.
Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format:
TXT=63879 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445,
RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034,
RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597,
RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD)
4035 Protocol Modifications for the DNS Security Extensions. R.
Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005.
(Format: TXT=130589 bytes) (Obsoletes RFC2535, RFC3008, RFC3090,
RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates
RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007,
RFC3597, RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD)
Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS
Do you use TLS for every web page you visit? Do you use it for all the email you deliver? Receive? FTP sites you visit?
It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures
Many tools do exist, as does hardware, to help with that process. I certainly do agree, though, that if you're trying to publish a large zone (say.com) on a very frequent basis (sub-hourly) you'll hit problems. That's always a problem with cryptographic solutions. (note: there is no requirement to pre-compute the signatures; you could compute them on the fly but that has other issues).
The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.
Look again.
How was this post not modded a troll?
As the lead-developer of a popular software package that is BSD based, I think you have to make a decision on a case by case basis. What is often overlooked is what type of help you want to attract. If your package is such that you want to attract the hobbyists, the system administrators, the co-users, etc then GPL is great because it provides you the ability to always suck that code back in. But... It scares off the corporations that may otherwise have helped.
In my case (I mention which package it is, but that's not the point) my package is getting distributed with most major OSes out there (osX, solaris, linux, freebsd,... ok, not windows but you can use it there). Why do they pick it? Why do many of them give patches back? Why are funds directed to improving the project? Because they *can* extend it and yet still feed back important patches without worrying about having to release everything it touches. I'm quite confident that we would not have attracted nearly as much help if it was GPL based.
Now, my most recent OSS project I'm releasing as GPL(v2) because my audience is different. Just like public speaking, you have to know your audience in order to select the right OSS license to release your code under.
I'm actually fairly surprised the slashdot editors don't have a treo and follow palmgear or other palm development sites. There already is a bar code scanner you can get for free for your treo:
I mean, we never have leaks! You never get that "Wow, I never saw this coming kind of viewpoint".
In the news today: Somone built an early release of KDE by hacking into their publically available anonymous SVN repository and downloading the code. They then released screen snapshots to the Internet. We now turn to our live reporter in bit-land with this breathtaking story...
I just wonder what the kids that mutate because of this will be able to do. The ones who adapt to survive will be the interesting ones to watch. Those silly LED keychains for finding a hot-spot will be obsolete.
The power point for my hifi setup is behind a shelf and there is no way to easily reach it so that option is out.
Oh come on... You MUST have seen one of those X10 advertisements in the last few years. That'll solve your problem right away. Then you can leave an X10 receiver in standby mode instead!
I only want to see the dupes. Really no seriously I'm not kidding!
Me too. I figure, if it's been duplicated it must be a story worthy of my attention. It's all the non-dups that must be worthless because only one reviewer posted it.
Re:No language that I like better
on
What is Perl 6?
·
· Score: 1
Classes are really just blessed hashes in Perl 5.
Now now... that's entirely unfair saying classes are just blessed hashes. This is perl... they wouldn't restrict you to just one way of doing something. You can actually bless anything, including arrays and scalars.
DOWNLOADING MORE SOFTWARE to intentionally disable part of a program that is supposed to work is 150% unacceptable.
I've always wondered why more browsers don't have JS enable/disable widgets by default. Konqueror has had this for eons and I love it dearly. My whitelist is small and is a trusted set of hosts. (now, the only problem with Konuqueror's JS implementation is that it fails on more sites than I'd like... Though 3.5 is supposed to be much better with JS.
You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be)
true
not if you want to prove authority (that the resource is being generated by the correct host)
The resource can't be signed by an incorrect host (holder of a key; not a host) unless the key has been stolen or broken. Obviously, if you don't have a trust anchor then an attacker can generate any key it wants if you'll believe it. With a trust anchor, however, you won't believe it.
or integrity (that the resource data hasn't been altered).
If altered the signatures won't validate and/or won't have a secure path from the trust anchors and integrity will fail. Again, without trust anchors an attacker can generate their own key and hopefully get you to use them (there isn't a secure protocol yet that has not resulted at some point to an out-of-band initial distribution in some way of root keys.
Meanwhile, existing attacks on DNS have involved subverting authority (by transferring names between nameservers without permission) and integrity (through cache poisoning)
Which don't work with DNSsec enabled and (big and) trust anchors in place and high up. Human attacks still work just fine though (such as talking a parent into signing a key for a zone that a human didn't have rights over).
Check RFC 4033 sec 3.1: It breaks Dynamic DNS if you sign your data offline.
Agreed. I should have mentioned it before, you're right. The practical solution that I've used in practice (and seen others use) is to put dynamic entries in their own zone which at least separates them out into records that require live keys.
I'll refrain from responding to the other trolling statements
What if someone hacked the root DNS servers? It's been done before.
If the roots get signed, they'll certainly going to be using off-line signing so the private half of the signing key won't be kept on the servers themselves. Thus, an attacker couldn't modify the data without people that were already aware of the public key wouldn't detect (and if they tried to change the key validating resolvers with the root keys installed as trust anchors would notice the difference and ignore the answers; end result a DoS at best instead of bogus data).
The major stumbling block to adoption is that the current specification of DNSSEC requires NXT records
Unfortunately true, though you could delete all those records and be subject to name injection. The NXT records (actually called "NSEC" by the way not NXT) just protect against proof of non existence. There is a new version called NSEC3 which uses hashed names to get around the data leak.
On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g.,.com) isn't in a signed zone.
FYI, there is at least some work being done on getting things signed by something other than your DNS parent. Look for the internet-drafts on "DLV" and the "lookaside" support in bind. It's unclear if this sort of work will advance in the IETF though.
RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole.com zone before they begin to expire. Anyone know any different?
That's not true... They have indeed signed the whole.com zone in practice on some fairly decent machines and it was on the order of hours (if I recall; I think 6), not months which is the more likely signature life time they'd pick
Slashdot Mirror
DNSSEC provides the ability for the data to be signed. The politics have come in, of course, as to who has those keys. (Now mind you, right now the US government or anyone at all can already spoof DNS responses today and interestingly enough when politics get involved, it takes longer for deployment of secure protocols to happen. whee....)
.com's key, because they're the one with all the data you need. The roots hold all the information about the TLDs, so you need to trust the roots to be able to get information about .com's servers. If someone controlled the keys for the roots and you trusted those keys (had them configured as "trust anchors") then they could spoof (signed) .com record, the .com keys, etc down until example.com so you'd trust the results for example.com as secure.
.com key instead. You don't have to trust the root zone keys, it just makes it easier to trust only one. Paranoid people are certainly welcome to maintain a list of trusted keys for any zones they deem to be "importantly" critical. If you had a trust anchor configured for .com, then it wouldn't matter what someone with the real root zone key could do with it... You wouldn't trust the eventual results from a fake .com server a root had told you about because the cryptography would warn you that it didn't match up to your expected trust anchor for .com. I suspect that most country TLDs will already do this for their own government results (IE, .se, who already runs a secured zone, will configure the .se keys as trust anchors in its government systems).
But, DNSSEC does provide every zone owner with the ability to hold a very special key so that no one else may be able to spoof stuff in their zone. Everyone would want to trust
But here's the secret: if you don't trust the root zone owners, then instead you can choose to set trust anchors tied to the
Here's an interesting proposal for the root zone: pick two countries that hate each other and are likely to never have the same agenda. Let's call them X and Y. Give each of these countries a root key, and make the root zone use and publish results from both of them. Then, you could configure trust anchors pointing to both the X and Y keys. You could configure your system to make sure to check the DNSSEC results to validate the information up to both of these keys. That way you could ensure that since you trusted X and Y to never conspire against you together, and you would know that neither X or Y alone could have spoofed DNS data then you suddenly find yourself safe. Because of the distrust. I love the irony.
(now: you don't want to have a zillion keys for the roots... The packet sizes get larger as you add more keys, and it turns out you probably don't want more than 3 at most).
oh, I think we may see a few
They are going to.
Wouldn't that preview button been a handy thing to press? Sigh...
The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie
I'm pretty sure that Paul knows about RFCs 4033-4035. I suspect you don't though.
Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS
Do you use TLS for every web page you visit? Do you use it for all the email you deliver? Receive? FTP sites you visit?
It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures
Many tools do exist, as does hardware, to help with that process. I certainly do agree, though, that if you're trying to publish a large zone (say .com) on a very frequent basis (sub-hourly) you'll hit problems. That's always a problem with cryptographic solutions. (note: there is no requirement to pre-compute the signatures; you could compute them on the fly but that has other issues).
The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.
Look again.
How was this post not modded a troll?
The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie I'm pretty sure that Paul knows about RFCs 4033-4035. I suspect you don't though. rfcfind -n '403[345]' 4033 DNS Security Introduction and Requirements. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=52445 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Status: PROPOSED STANDARD) 4034 Resource Records for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=63879 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD) 4035 Protocol Modifications for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=130589 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD) Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS Do you use TLS for every web page you visit? Do you use it for all the email you deliver? Receive? FTP sites you visit? It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures Many tools do exist, as does hardware, to help with that process. I certainly do agree, though, that if you're trying to publish a large zone (say .com) on a very frequent basis (sub-hourly) you'll hit problems. That's always a problem with cryptographic solutions. (note: there is no requirement to pre-compute the signatures; you could compute them on the fly but that has other issues).
The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.
Look again.
How was this post not modded a troll?
You'd think he should have been smart enough not to show up to work in a red shirt.
U bet they n3v3r b3 31337 h@x0rs!
In my case (I mention which package it is, but that's not the point) my package is getting distributed with most major OSes out there (osX, solaris, linux, freebsd, ... ok, not windows but you can use it there). Why do they pick it? Why do many of them give patches back? Why are funds directed to improving the project? Because they *can* extend it and yet still feed back important patches without worrying about having to release everything it touches. I'm quite confident that we would not have attracted nearly as much help if it was GPL based.
Now, my most recent OSS project I'm releasing as GPL(v2) because my audience is different. Just like public speaking, you have to know your audience in order to select the right OSS license to release your code under.
Then it wouldn't have gotten slashdotted... you could google for google games and click the google cache link instead!
I'm actually fairly surprised the slashdot editors don't have a treo and follow palmgear or other palm development sites. There already is a bar code scanner you can get for free for your treo:
BarCode
Of course, quality isn't perfect but it does work. Mostly. Reads the barcode and copies the number stream results to your clipboard.
I think that's your way of saying "I have the support. I have the binaries. I have the source. But where's the comments?"
Have you noticed you have two choices in life: Closed-Source with Documentation or Open-Source without (and no, the code doesn't count).
In the news today: Somone built an early release of KDE by hacking into their publically available anonymous SVN repository and downloading the code. They then released screen snapshots to the Internet. We now turn to our live reporter in bit-land with this breathtaking story...
5) Profit!!!
Instead, just ask Jed!
"err... over there" [points with finger]
I suddenly have the strange desire to watch Kevin Bacon dance... weird...
Oh come on... You MUST have seen one of those X10 advertisements in the last few years. That'll solve your problem right away. Then you can leave an X10 receiver in standby mode instead!
Me too. I figure, if it's been duplicated it must be a story worthy of my attention. It's all the non-dups that must be worthless because only one reviewer posted it.
Now now... that's entirely unfair saying classes are just blessed hashes. This is perl... they wouldn't restrict you to just one way of doing something. You can actually bless anything, including arrays and scalars.
I've always wondered why more browsers don't have JS enable/disable widgets by default. Konqueror has had this for eons and I love it dearly. My whitelist is small and is a trusted set of hosts. (now, the only problem with Konuqueror's JS implementation is that it fails on more sites than I'd like... Though 3.5 is supposed to be much better with JS.
true
not if you want to prove authority (that the resource is being generated by the correct host)The resource can't be signed by an incorrect host (holder of a key; not a host) unless the key has been stolen or broken. Obviously, if you don't have a trust anchor then an attacker can generate any key it wants if you'll believe it. With a trust anchor, however, you won't believe it.
or integrity (that the resource data hasn't been altered).
If altered the signatures won't validate and/or won't have a secure path from the trust anchors and integrity will fail. Again, without trust anchors an attacker can generate their own key and hopefully get you to use them (there isn't a secure protocol yet that has not resulted at some point to an out-of-band initial distribution in some way of root keys.
Meanwhile, existing attacks on DNS have involved subverting authority (by transferring names between nameservers without permission) and integrity (through cache poisoning)
Which don't work with DNSsec enabled and (big and) trust anchors in place and high up. Human attacks still work just fine though (such as talking a parent into signing a key for a zone that a human didn't have rights over).
Check RFC 4033 sec 3.1: It breaks Dynamic DNS if you sign your data offline.
Agreed. I should have mentioned it before, you're right. The practical solution that I've used in practice (and seen others use) is to put dynamic entries in their own zone which at least separates them out into records that require live keys.
I'll refrain from responding to the other trolling statements
If the roots get signed, they'll certainly going to be using off-line signing so the private half of the signing key won't be kept on the servers themselves. Thus, an attacker couldn't modify the data without people that were already aware of the public key wouldn't detect (and if they tried to change the key validating resolvers with the root keys installed as trust anchors would notice the difference and ignore the answers; end result a DoS at best instead of bogus data).
Unfortunately true, though you could delete all those records and be subject to name injection. The NXT records (actually called "NSEC" by the way not NXT) just protect against proof of non existence. There is a new version called NSEC3 which uses hashed names to get around the data leak.
There is also the requisite sourceforge project with additional helpful tools: www.dnssec-tools.org
On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g., .com) isn't in a signed zone.
FYI, there is at least some work being done on getting things signed by something other than your DNS parent. Look for the internet-drafts on "DLV" and the "lookaside" support in bind. It's unclear if this sort of work will advance in the IETF though.
That's not true... They have indeed signed the whole .com zone in practice on some fairly decent machines and it was on the order of hours (if I recall; I think 6), not months which is the more likely signature life time they'd pick