Err... I think you have some facts missing. I've written a quick Maemo5 app using vi and their SDK debian-based environment. (I've never used Eclipse for anything before).
So... In essence you're saying that for WiMo every once in a while you need to format and reinstall? Now... what other OS have I seen that advice attached to before.
The humor for me with your comment (not that I have mod points) is that RFC2246 is obsolete:
# rfcfind -n 2246 2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. (Format: TXT=170401 bytes) (Obsoleted by RFC4346) (Updated by RFC3546) (Status: PROPOSED STANDARD)
And what's better, is that RFC4346 is ALSO obsolete
# rfcfind -n 4346 4346 The Transport Layer Security (TLS) Protocol Version 1.1. T. Dierks, E. Rescorla. April 2006. (Format: TXT=187041 bytes) (Obsoletes RFC2246) (Obsoleted by RFC5246) (Updated by RFC4366, RFC4680, RFC4681) (Status: PROPOSED STANDARD)
So, you're yelling at them for using old terminology and documentation when in fact you're doing the same!
Does anyone else worry about the day that some big asteroid is heading for earth? Then earthlings actually band together for once and reach consensus about firing a nuke toward the planet and all the scientists agree it'll work. But then it hits something in orbit as it heads out because all the launch windows are so complex just due to the stuff we've put up there?
You might volunteer for the Red Cross. They are always in need of people to help set up communication equipment during a disaster (when it becomes critical they have it!). Which, of course, means getting involved with them early so you can learn about what equipment the local chapter has and help them organize and test it and plan on using it and...
And, as a side benefit, you'll likely learn something from them too. Not only will you get trained in various emergency operation skills, you'll likely even learn about new tech. areas that you don't know much about yet as they have a very wide and diverse set of communication equipment.
1) Traffic for the signing of records would increase
exponentially
DNS zones are about 3-4 times larger in general with signed records
in them.
because to establish the authenticity you'd have to
contact the originating server and do a PKI-like transaction (that's
expensive).
Unfortunately, all security typically revolves around doing
computational tasks by proving something cryptographically. The DNS
client in DNSSEC is tasked with validating PKI signatures if they want
to trust the data... The servers serving DNSSEC-enabled zones,
however, only serve the data. The data is pre-signed and isn't signed
for every transaction so their hit CPU wise is minimal (they just have
more data to serve).
In it's current form, forcing DNSSEC throughout the world
would effectively bring down the root DNS servers as well as many
others
The root server operators disagree with you here... For them,
they've said they're ready today to serve a signed root. Most of
their problems (something like 90% of their traffic) comes from by
clients that keep asking for stupid things like
"localhost.localdomain"
2) Because of 1) caching DNS servers would be less useful since you'd
have to contact the original for the keys anyway. This also
introduces the problem that if all the original DNS are unreachable
for whatever reason the whole zone would become unusable whereas
now they have been cached.
Caching servers cache the keys and signatures just like any other
record. They have to cache more, but the number of requests doesn't
go up by huge amounts. Again, it does require more data to be stored
though but it's not "exponential"
3) There is an attack vector where by using the no-record responses
somebody can obtain the whole zone even if you didn't intend to
publish it
Agreed, though NSEC3 (RFC5155) was designed to solve that
particular problem, though it has it's own oddities about it. Many
TLDs were waiting for that to begin the signing of their TLD zones
(.uk and.org being some of the outspoken ones).
There are multiple implementations of DNSSEC for debian in the core repository. The latest bind tools support it and dnssec-tools is available packaged for debian.
By far one of the best enhancement packages to come out for (X)Emacs in a long time is org-mode. It's a feature-full organization and agenda system that all operates on plain text files that are easy to read and write.
except with git you can create local branches, work disconnected, don't need to give commit privs. out as much, and it's much faster.
You might try SVK sometime if you get a chance. It's sort of in between SVN and git. It basically is a fancy wrapper around SVN that lets you syncronize with multiple repositories and do push/pull type operations to merge stuff together. I've used it extensively when traveling on a plane to work offline from a svn server and then push everything back in incremental chances once I get to network access again.
In short, svk rocks. It's one big downside, though, is that it's slower in execution time. (since it doesn't need network access, diffs and logs and stuff are faster but the actual execution of the binary to do anything is a bit slower).
You have to decide if you want to trust your ISP to do validation for you or if you want to do validation yourself (the average Joe will likely have this decided for them). If you trust your DSL (whatever) link to your nearest validating resolver (you're ISPs) and you trust your ISP, then you have functionally a secure(ish) path. If you're more paranoid, then get a on-system validating resolver or validating applications (the DNSSEC-Tools project has a validating version of firefox2).
And the DS record (which is a hash of a childs key) is signed so there is a secure trust path from root to final DNS entry being resolved. Glue, as you pointed out, is not signed but that's because a parent isn't authoritative over glue records. The best you can get with spoofing glue is a DoS.
Just like HTTPS and PGP require keys to get you started with your "trust", so does DNSSEC. With HTTPS you have a set of root CAs that you trust to issue certificates to web sites. Browsers, in fact, distribute a fairly mind numbingly large number of CAs that they accept as authentic providers of SSL certs to be trusted. PGP requires that you boot-strap your own trust by finding keys of all your friends before they send you important data you need to authenticate.
DNSSEC is really no different. The only question is, what's your bootstrapping set of keys. The advantage of waiting for the root to get signed is that you might be able to have just a single set of keys to serve as your "trust anchors".
And, it's entirely possible, for example, that even if the root was signed you'd trust some subdomain's key with a higher level of trust. EG, example.com might trust it's own key more than.coms. Just as it's possible to come up with obtuse security requirement scenarios for any other cryptographic trust policy, you can do the same thing with DNSSEC.
And, even if the root was signed today.com,.org and.net aren't. So if you have example.com you're already missing a trust link because there is no way to get securely from the root to example.com with that nasty break in the middle. And it's equally unclear when.com is going to get signed just as it's unclear when the root is.
Security always comes down to: who do you trust to tell you who you can trust.
I nearly feinted when I read that
on
Cisco To Buy Jabber
·
· Score: 3, Funny
... But primarily because I misread Jabber as "Juniper".
Agreed. However, I think it's going to get much much worse. It's not bad right now because there isn't much of it. What I worry about is ending up more along the lines of The Truman Show where the characters talk about the products, etc, in cheezy ways.
I, too, would rather have product placement than many other forms of advertising. What worries me is how bad product placement could get. Assume that ad companies wise-up and remove all web advertising, all tv ads, etc, because they realize everyone skips them. Now imagine all that energy directed into product placement because that's the only way for them to get advertising... It'll get insane. That's my worry.
It isn't my problem to come up with a "winning" solution. If I can skip the ads, than I will. Let the marketing geniuses come up with a solution to that (let's hope it's not a legislative solution).
Unfortunately, we're headed down a path where no one has the solution and either side is doing stupid things. The users want everything for free (why wouldn't you). Since everything is digital and can be manipulated then you can strip anything you don't want from everything. The commercial industry wants as much money from you as possible (why wouldn't they) so they're trying to make creative ways to ensure you must be able to see things like ads (no-skip DVD portions, javascript requirements, flash requirements, DRM for everything,...).
Where does that leave us. With only one solution: integration. Product placement in TV shows, flash-based web interfaces, etc.
We will head toward a place where the two worlds collide and it'll be a buzz of too much information within the content you want to look at because separation will be nigh-impossible. Until someone creates a DVD player that can look for a can of coke in a video image and edit it out on the fly and replace it with a can of pepsi or other drink based on your preferences.
Slashdot Mirror
Err... I think you have some facts missing. I've written a quick Maemo5 app using vi and their SDK debian-based environment. (I've never used Eclipse for anything before).
So... In essence you're saying that for WiMo every once in a while you need to format and reinstall? Now... what other OS have I seen that advice attached to before.
Sadly, I think it's November for everywhere.
http://talk.maemo.org/showpost.php?p=355093&postcount=423
And what's better, is that RFC4346 is ALSO obsolete
So, you're yelling at them for using old terminology and documentation when in fact you're doing the same!
You do realize you could have shortened your post to one word, right: Fail!
Does anyone else worry about the day that some big asteroid is heading for earth? Then earthlings actually band together for once and reach consensus about firing a nuke toward the planet and all the scientists agree it'll work. But then it hits something in orbit as it heads out because all the launch windows are so complex just due to the stuff we've put up there?
And, as a side benefit, you'll likely learn something from them too. Not only will you get trained in various emergency operation skills, you'll likely even learn about new tech. areas that you don't know much about yet as they have a very wide and diverse set of communication equipment.
The summary and most posts seem to be talking about both...
1) Traffic for the signing of records would increase exponentially
DNS zones are about 3-4 times larger in general with signed records in them.
because to establish the authenticity you'd have to contact the originating server and do a PKI-like transaction (that's expensive).
Unfortunately, all security typically revolves around doing computational tasks by proving something cryptographically. The DNS client in DNSSEC is tasked with validating PKI signatures if they want to trust the data... The servers serving DNSSEC-enabled zones, however, only serve the data. The data is pre-signed and isn't signed for every transaction so their hit CPU wise is minimal (they just have more data to serve).
In it's current form, forcing DNSSEC throughout the world would effectively bring down the root DNS servers as well as many others
The root server operators disagree with you here... For them, they've said they're ready today to serve a signed root. Most of their problems (something like 90% of their traffic) comes from by clients that keep asking for stupid things like "localhost.localdomain"
2) Because of 1) caching DNS servers would be less useful since you'd have to contact the original for the keys anyway. This also introduces the problem that if all the original DNS are unreachable for whatever reason the whole zone would become unusable whereas now they have been cached.
Caching servers cache the keys and signatures just like any other record. They have to cache more, but the number of requests doesn't go up by huge amounts. Again, it does require more data to be stored though but it's not "exponential"
3) There is an attack vector where by using the no-record responses somebody can obtain the whole zone even if you didn't intend to publish it
Agreed, though NSEC3 (RFC5155) was designed to solve that particular problem, though it has it's own oddities about it. Many TLDs were waiting for that to begin the signing of their TLD zones (.uk and .org being some of the outspoken ones).
There are multiple implementations of DNSSEC for debian in the core repository. The latest bind tools support it and dnssec-tools is available packaged for debian.
You'd have to back up many of those claims as at least half of them don't make sense or are inaccurate. Troll anyone?
Useful(Stupid) things to say to get modded Insightful
Useful(Stupid) things to say to get modded Interesting
Useful(Stupid) things to say to get modded Funny
Useful(Stupid) things to say to get modded Troll
Useful(Stupid) things to say to get modded Redundant
Useful(Stupid) things to say to get modded Flamebate
Useful(Stupid) things to say to get modded Overrated
Useful(Stupid) things to say to get modded Stupid
Useful(Stupid) things to say to get modded Useful
Slashdot posted a story about useful vi tips, realized that it sucked and wrote a story about Emacs: new and better.
(yeah yeah yeah... slashdot doesn't write stories and just approves them; I know...)
By far one of the best enhancement packages to come out for (X)Emacs in a long time is org-mode. It's a feature-full organization and agenda system that all operates on plain text files that are easy to read and write.
except with git you can create local branches, work disconnected, don't need to give commit privs. out as much, and it's much faster.
You might try SVK sometime if you get a chance. It's sort of in between SVN and git. It basically is a fancy wrapper around SVN that lets you syncronize with multiple repositories and do push/pull type operations to merge stuff together. I've used it extensively when traveling on a plane to work offline from a svn server and then push everything back in incremental chances once I get to network access again.
In short, svk rocks. It's one big downside, though, is that it's slower in execution time. (since it doesn't need network access, diffs and logs and stuff are faster but the actual execution of the binary to do anything is a bit slower).
Does this mean you're going to buy the review?
You have to decide if you want to trust your ISP to do validation for you or if you want to do validation yourself (the average Joe will likely have this decided for them). If you trust your DSL (whatever) link to your nearest validating resolver (you're ISPs) and you trust your ISP, then you have functionally a secure(ish) path. If you're more paranoid, then get a on-system validating resolver or validating applications (the DNSSEC-Tools project has a validating version of firefox2).
And the DS record (which is a hash of a childs key) is signed so there is a secure trust path from root to final DNS entry being resolved. Glue, as you pointed out, is not signed but that's because a parent isn't authoritative over glue records. The best you can get with spoofing glue is a DoS.
Just like HTTPS and PGP require keys to get you started with your "trust", so does DNSSEC. With HTTPS you have a set of root CAs that you trust to issue certificates to web sites. Browsers, in fact, distribute a fairly mind numbingly large number of CAs that they accept as authentic providers of SSL certs to be trusted. PGP requires that you boot-strap your own trust by finding keys of all your friends before they send you important data you need to authenticate.
DNSSEC is really no different. The only question is, what's your bootstrapping set of keys. The advantage of waiting for the root to get signed is that you might be able to have just a single set of keys to serve as your "trust anchors".
And, it's entirely possible, for example, that even if the root was signed you'd trust some subdomain's key with a higher level of trust. EG, example.com might trust it's own key more than .coms. Just as it's possible to come up with obtuse security requirement scenarios for any other cryptographic trust policy, you can do the same thing with DNSSEC.
And, even if the root was signed today .com, .org and .net aren't. So if you have example.com you're already missing a trust link because there is no way to get securely from the root to example.com with that nasty break in the middle. And it's equally unclear when .com is going to get signed just as it's unclear when the root is.
Security always comes down to: who do you trust to tell you who you can trust.
... But primarily because I misread Jabber as "Juniper".
No, what'll really happen is we'll have Ubuntu8: CowboyNealCar
SCO stuff may be finally worth something...
1) go bankrupt
2) sell furniture on EBay
3) get amazed when Darryl's chair sells for one millllion dollars
4) profit!!!
Look MA, no question marks!
That one is my favorite too (though I used to use a cssv1 version that is very similar and the sources are obviously similar.
I also really like the diagram in this one but don't like how the rest of it is organized. Which is too bad because anyone that owns a domain name of ilovejackdaniels.com deserves more positive praise.
It was:
Finally, we have an answer. I believe this is the first time that a slashdot ??? marking can be filled in!
Agreed. However, I think it's going to get much much worse. It's not bad right now because there isn't much of it. What I worry about is ending up more along the lines of The Truman Show where the characters talk about the products, etc, in cheezy ways.
I, too, would rather have product placement than many other forms of advertising. What worries me is how bad product placement could get. Assume that ad companies wise-up and remove all web advertising, all tv ads, etc, because they realize everyone skips them. Now imagine all that energy directed into product placement because that's the only way for them to get advertising... It'll get insane. That's my worry.
Unfortunately, we're headed down a path where no one has the solution and either side is doing stupid things. The users want everything for free (why wouldn't you). Since everything is digital and can be manipulated then you can strip anything you don't want from everything. The commercial industry wants as much money from you as possible (why wouldn't they) so they're trying to make creative ways to ensure you must be able to see things like ads (no-skip DVD portions, javascript requirements, flash requirements, DRM for everything, ...).
Where does that leave us. With only one solution: integration. Product placement in TV shows, flash-based web interfaces, etc.
We will head toward a place where the two worlds collide and it'll be a buzz of too much information within the content you want to look at because separation will be nigh-impossible. Until someone creates a DVD player that can look for a can of coke in a video image and edit it out on the fly and replace it with a can of pepsi or other drink based on your preferences.