Try NOD32. The scanner that actually got top ratings in this test, for finding the highest number of viri without ungodly number of false positives.
I've used it for a few years, and it's fast and has a good track record on virus tests.
Can't recommend enough.
One machine, at least 2 monitors, and as much ram as you can afford.
With quad and octo core machines readily available, it's a no brainer. But go for the 64 bit version of your favorite OS and gobs of ram. A few hard drives in raid 5 or 10 always help. A great keyboard, mouse, and 3 monitors will complete the developers god box.
Really, CPUs are ridiculously fast, and it's all about the IO devices and memory today.
Allows for rolling over keys in ways that do not break the trust relationship.
There is no new trust relationship; The parents simply sign the signing key. Exactly what trust can be inferred from that is independent of DNS.
There is a time in the roll-over where you have published a new key, but the old key is still cached. How does DNSCurve deal with this?
About new encryption options:
Much like HTTP, DNSSEC can be extended by wherever both endpoints support. OS a new client would get fancy ECC encryption, and older DNSSEC capable versions would get RSA. Over time as people upgrade, RSA gets turned off. That's how compatibility works in the real world.
DNSCurve has some good design decisions, but there are many corner cases that DNSSEC solves that DNSCurve does not address. Still, given time it could be usable, but it's not that much better. DNSSEC deployment can be as easy if you like, offers the same level of protection against MITM attacks, and in general is good enough. You obviously don't think so, but the DNSCurve site pits the best possible deployment options for DNSCurve against the worst possible deployment senario for DNSSEC. DNSSEC can be plug-in simple also.
The only real wins for DNSCurve are smaller packets today, and router compatibility. Its downsides are poor key management management and future upgrade path, and even if the tradeoff was worth it (which I don't believe it is), it's not worth throwing away the momentum DNSSEC currently has.
We all wish DNSSEC could be simpler, and if DNSCurve was really much easier to deploy for the same security, I'd be all over it. However, I don't believe it is. Good deployment tools exist for DNSSEC and many more will be created, but DNSCurve's security downsides in key management can't be automated away.
1. I have, it has the same attacks with the same problems. He redefines DOS attacks as simple forgery resilience, which DNSSEC also supports. DOS problems with DNS commonly seen are resource or network consumption issues, on the client, server, or as an amplifier of an attack against a 3rd party. DNSSEC and DNSCurve both do no affect any of these issues besides making them worse. But maybe I'm wrong; the specs suck and there's no implementation to play with. Give me an example where DNSCurve provides protection DNSSEC can't.
2. DNSSEC is extensible, and the hard work of protocol design is done up front. New encryption methods can be added and migrated in backwards compatible in stages, while to upgrade DNSCurve you'd need to design a whole new protocol. Yes, this does make converting to DNSSEC more difficult up front, but DNSSEC is a much better long term solution.
3. No, they are not. NSD is from scratch and the code is available in SVN to verify that. I'm not privy to all the details of the others but some of them do claim to be from scratch. Overall, it doesn't matter. Most (11) vendors support DNSSEC, can you point to one actual implementation of DNSCurve? How about 11 inter-operable implementations?
4. Yes, non-compliant routers are a problem, I admit. Not a large one, as I posit that before end users care about DNSSEC or have software that is requesting DNSSEC information, they will be replaced or upgraded. Windows 7 "pre-betas" which have been released have DNSSEC support, and will be the first end user systems to be compliant.
5-6. DNSCurve needs support all along the chain of trust to the root to be secure. DNSSEC needs support all along the chain of trust to the to root to be secure. Notice the similarity? There are a myriad of attacks against DNS, some where external parties force resolving of domains through various means (think image tags in HTTP). DNSSEC and DNSCurve have the exact same attack profile against all of these attacks.
The interaction between the parent and child is easier with DNSCurve, but because of this there is no way to roll over keys in a manner that doesn't break the security of the system. Otherwise they act the same way.
Main benefits of DNSCurve: Crappy routers allow it to pass. Some privacy protection given by encrypting transfers, though doesn't protect against traffic analysis. Supports smaller ECC today. Less complicated method of authenticating non-existence of domains. Overall, less complicated.
Main benefits of DNSSEC: Tested, secure, with design docs and very good specifications. Widely implemented in software, though not yet widely deployed. Allows for very strong key protection for high profile sites, or less security and more convience for low profile sites. Uses time tested RSA, not a 2 year old ECC variant. Can later switch to ECC if desired. Allows for rolling over keys in ways that do not break the trust relationship. Allows for easily adding multiple encryption algorithms. Overall, more flexible.
In terms of likelihood of deployment, DNSSEC is far ahead: Mandated by US government and military for deployment in their networks. Deployed by multiple ccTLDs. Being tested at the root and reverse zones. Multiple ISPs have public DNSSEC testbeds.
1. DNSSEC does in fact make DOS attacks worse in the very same ways DNSCurve makes DOS worse: Resource usage and bandwith. However, DNSCurve makes authoratative server computer useage worse, while DNSSEC does not. DNSSEC with RSA makes bandwith useage worse then DNSCurve with ECC, which is why DNSSEC will soon support ECC.
2. DNSCurve misses a lot of the extensibility and forward compatibility including ability to roll over keys, have offline signing, and switch to new crypto alogorithms. All those things are important to a long time secure DNS.
3.This is not true. Namesurfer Suite has both a BIND based and proprietary DNSSEC aware server, NLNET labs has NSD and Unbound, Xelerance and Nominum now supports dnssec, and many more. There's a nice chart of capabilities in this report on page 5 and 6, and more have been added since then.
4.This is a tool problem, and many tools are avalible and being made to make this simple.
5. This is false. True, the parents do not need to modified to accept DNSSEC KEY records like they do for DNSSEC, but the parents themselves must use DNSCurve, or the chain of trust is broken and the protection of that one link is meaningless. In both schemes, the parent must support the security standard to gain anything.
6.This is not true. The end-user needs the root key ahead of time, and then there is NOTHING a MITM can do to convince the client that the information shouldn't be signed. This sort of attack is why the chain of trust from the root is important, and similar to the reason why the NSEC or NSEC3 records must exist. DNSSEC provides much stronger resilience in the case of MITM then DNSCurve.
That is a policy decision not covered by the DNSSEC standards.
He would have to do that for all traffic to the root and TLD servers for that attack to be affective, and you would have to be set up in a way that would allow unsigned root traffic as valid.
Which is to say, no, that attack won't work for any sane deployment.
DNSSEC support is in the current pre-beta releases of Windows 7, and I'm sure it will get added to their next server platform release also.
The requirement to sign all.gov domains by next year means MS has to support it or lose government support. Though personally I hope no government agencies are using MS DNS servers, that's a different rant...
Ah, DNSSurve seems to claim to protect against DOS attacks by a MITM. Honestly the MITM problem is the LEAST of the DOS attack problem, and there's no reason DNSSEC servers couldn't be trivially modified to behave the same way. In fact DNSSEC is silent on how to handle badly signed or corrupted packets, and that sort of DOS breaking capability is within the standards.
The classes of DOS attack mentioned in RFC 4033 (resource and bandwidth consumption ) as well as the ability to use DNS as a DOS amplifier work the EXACT same way against DNSCurve. Perhaps I am missing something, but the DNSCurve docs are poor and incomplete and don't mention DOS anywhere but in that blurb.
Here's why the DNSCurve chart is a bunch of crap:
1) He attacks NSEC3 as already reversable. This is blatantly false, SHA-1 currently used is MUCH harder to reverse then simply querying the server. If SHA-1 fails, new signing algorithms can be used instead. The way that NSEC3 CAN be attacked is through a dictionary attack, and if you have dictionary words as DNS names, they can be recovered just as easily by brute-forcing the server. The protection is the same, as you only get a limited amount of NSEC3 records per query also, so server side protections against brute forcing DNS records would be the same sorts of protections against querying for all NSEC3 records.
2) He attacks DNSSECs use of 1024 bit RSA. DNSSEC does have RSA as the only manditory public key cypher, but it does NOT specify bitlength. 2048 bit keys as key signing keys are the likely length at first, and 1024 bit is just a strawman that doesn't exist in the specs. As already discussed, DNSSEC can be, and is in the process of being extended to use ECC or any other public key crypto.
Here's the case for why DNSCurve isn't good enough:
DNSCurve REQUIRES that the signing key be online.
DNSSEC can operate with the signing key online, and gets easy deployment on the server side. The only way it would be harder then DNSCurve is that you have to send your parent server a DNSKEY in addition to a glue record. It's still a copy paste on your side, but it does require your parent is DNSSEC aware.
Alternatively you can operate in off-line mode, where you have to do the signing offline on a non-connected machine, and copy the records back to the server.
DNSSEC deployment dificulty is a tool issue, and there are a number of good deployment tools written that take the difficulty out of it. DNSCurve is simple by design, but not secure and not flexible. The only place it is more difficult in the parent-child relationship.
DNSCuve would have horrible political problems. DNSSEC is currently waiting on political, not technical issues. You think the current squabble over who holds the signing key is bad? With DNSCurve, you HAVE to put the signing key online at every root server. In DNSSEC, you have the root signing key in a hardware key holding box, and put armed guards around it. One of these is massively more secure then the other. If that root key is compromised, DNSSEC has ability to cleanly roll over to a new key with a prepublish scheme, DNSCurve do to its simplicity has no mechanism.
DNSCurve seems like a good idea due to its simplicity, but DNSSEC can have similar simplicity with the right tools, but also has the flexibility to adapt from that easy, low maintenance but less secure deployment to high-security and guys with guns deployment. DNSCurve fails because if its simplicity and inflexability
All in all, DNSCurve is where DNSSEC was 10 years ago, with a cool idea but not covering all the use cases needed. Sorry, but DNSSEC does what we need, and it does it now.
Remember: The recent DNS bugs were predicted over a decade ago. The BIND group said don't worry, we'll have DNSSEC done soon, but other DNS server vendors (all those not based on BIND) adopted the very simple method of being immune to them.
No one had simple ways of being immune. 2 vendors had the port randomization turned on, far from everyone not BIND. It was a smart hardening step, but it doesn't make them immune to the currently known attacks. If it did, we wouldn't be having this conversation.
Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.
I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.
DNSSEC is currently deployed live in multiple countries,.gov and.arpa are now signed (but only for testing purposes at the moment).
Yes, the number of DNSSEC hosts is only in the low 5 digits, but that's still way more then DNSCurve. 11 vendors have DNSSEC compatible DNS servers, which I believe is 11 more then DNSCurve. DNSCurve would have to be significantly
better in order to garner support at this stage, and I'm not seeing it.
DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.
DNSSEC is not.
This is a valid point. Only about 1/4 of recently tested home routers allowed DNSSEC traffic. It's also a problem that is trivial to solve in the long term. Once DNSSEC is deployed, routers will follow. Realistically however, all home routers will be DNSSEC capable before Windows can deal with the DNSSEC data. DNSSEC can still make policy decisions at the ISPs recursive resolver before that time however.
DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.
Strange that the link you send doesn't mention DOS attacks at all.
DNSSEC requires 0 more compute power, but does increase network traffic. DNSSEC can be extended to use ECC instead of RSA to reduce the network overhead, with NO computational overhead.
I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.
I don't think you know what you're talking about.
Oh? Read RFC 4034, then get back to me. Elliptic curve crypto already has a specified algorithm type, listed in appendix A.1. Unfortunately, the exact format hasnt been standardized yet. There are 245 more unassigned crypto specifications available for future use, I'd call that extensible.
DNSCurve does have some good ideas since it was designed to be easy to deploy, while DNSSEC deployment frankly sucks. DNSSEC is designed by committee,and it shows. On the other hand, it has many future-proof features like the ability to upgrade the crypto used in case RSA, DSA, ECC, or any other scheme falls like a house of cards, or simply need to be made longer in order to survive attacks.
If DNSCurve was proposed 5 years ago, it would have had a good chance of becoming the standard. Now, frankly, it's too late. Most of the major DNS servers support DNSSEC,.gov is currently signed and all US government sites must use DNSSEC by next year, the root servers and reverse.arpa domains have DNSSEC testbeds, Comcast has deployed their dnssec test servers. The political problems of who holds the root keys will be solved soon and DNSSEC will be live. Whether it takes off or not is a question for the market to decide.
Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.
DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.
It's hard to make a case for the need to protect the DNS traffic from sniffing, the threat is modification, not sniffing.
I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.
Comcast is currently running publicly available DNSSEC enabled testbed: http://www.dnssec.comcast.net/
All the service providers are fed up with having to rush to patch all their DNS servers for a major break about once a year, and the time is right to convince them to switch after the largely publicized Kaminsky bug.
There are 2 major hold ups on DNSSEC adoption: The root is not signed, and Microsoft doesn't support it.
Pretty much every other DNS server besides MS supports DNSSEC, and most now support the privacy preserving NSEC3 variant also.
Personally, I don't care if ISPs support it right away as I run my own recursive nameserver and avoid my ISPs like the plague, but I know that puts me in.00001% of the Internet.
DNSSEC *IS* fixing the bug. It's a protocol problem, and needs a protocol level fix. DNSSEC is an extension of the DNS protocol, and if any party in the transaction doesn't support it or ask for it, DNS still acts just like DNS. If the resolver asks for DNSSEC information, and the DNS server supports it, then you get the normal DNS information + the DNSSEC information.
This is NOT switching to a new platform, it's adding a signature to the existing platform for verification. It can work precicely because it is backwards compatible, and doesn't require everyone switch at once.
It DOES pretty much require a signed root, which is the primary hold up. However, at the moment there are countries where the top level domains are signed, and have a fairly good deployment of DNSSEC.
Not really hard, but it contains a fraction of the things available for Ubuntu or Debian testing, and seems to be more out of date also.
In the Ubuntu repositories I currently am using, there are 26K packages. Macports has 5k. Darwinports has 4k. Maybe they have the software and libraries you use, but they don't contain lots of things I use.
This is one of the major issues that keeps me on Linux. Despite the fact you can get almost anything to run on OS X eventually, for most software it's much much harder to get up to date software versions then "apt-get install fizzbuzz" on Ubuntu or debian testing.
For my needs, Ubuntu is much closer to the "just works" ideal then OS X.
I vote developer issue. The low-end mac mini hasn't had an update in years. If you want to hook up and coming developers, you need a cheap platform to let them experiment on. A mid tower would fit that much better then their current offerings. Of course, a newer mac mini would be a change in the right direction...
Compared to MS office, OO Writer is mostly as good as Word, and for me OO Calc is better then Excel, but Impress and Base still suck relative to their MS Office counterparts.
Impress is far too slow in rendering, to the point that I refuse to use it for any new presentations. Instead I've found that LaTex Beamer and keyjnote do everything I want faster and easier.
Ubuntu isn't the great savior, but they did take the excellent Debian base and offered polish, support, and most importantly, marketing. They've also forced other players such as Fedora to up their game in order to stay competitive. All in all, Ubuntu has done good things for the Linux space, but still Linux market share is tiny.
For many nerds these days, at least among the security and programming nerds I hang out with, the competition isn't Linux/Microsoft anyway, it's Linux/Apple.
Best Buy makes their money on cables and extended warranties. Never buy either at Best Buy. They even have their own cable line for this purpose (Dynex).
And this is the difference. High quality headphones work in the space you have, to get a great listening experience with speakers you need a new house built around your listening space..
There is a middle ground, I often listen to my Grado headphones with the speakers off and my subwoofer on for the full experience.
Care to post support for that statement? FF w/ tracemonkey beats everything else in most benchmarks I have seen yet in pure javascript tests. Safari and Chrome beat Firefox 3.1 sometimes in DOM heavy tests, but I've yet to see a benchmark where Opera beats FF 3.1 W/ or without the new "tracemonkey" VM enabled. See: http://ejohn.org/blog/javascript-performance-rundown/
Wrong. HTML 4.01 compliant would pass as compliant in this test. Heck, even valid HTML 2 or 3.2 would be compliant.
What this survey says is that 96% of webpages have at least one non-standard element included, or other violation of the standards.
I'd be interested in seeing a more detailed breakdown on the reasons: If a page is 99% standards compliant with one non-standard element for telling the browser not to store the password(for example, reddit.com), that's a lot different from badly nested and missing tags, etc.
I write and use security tools that parse HTML, and getting them to correctly handle all the poorly formed HTML out their is an absolute b*tch. Even libraries like beautifulsoup that are supposed to handle that still miss and break on a lot of input that modern web browers accept. I can't tell you how much easier full XHTML compliance would make my work, but even valid HTML 4.01 would be a FAR improvement over what passes for websites out there.
Unfortunately, even my employers site is not valid HTML of any sort either... That wasn't one of the qualifications of the system that was chosen, instead ease of use of the system was the qualifier. It claims to be XHTML transitional, but does not validate.
The good news is that standards compliance is on the rise. They included this table, showing % compliance found in their survey and similar surveys in the past: Parnas Dec 2001 0.71% Saarsoo Jun 2006 2.58% MAMA Jan 2008 4.13%
They also found that 33% of pages used flash! Really? Noscript has kept me from noticing that I guess..
Lets say I'm a road builder, and I know your 2001 Microsoft Road Explorer sucks and would cause me many hours of work to work around it's bugs.
Lets say I decide I'm not planning on doing that extra work in my future roads, and I put up a sign telling you that your car is faulty and you should go to your dealer for a FREE safety and functionality upgrade.
It's hard to argue that that is a bad thing to do. </car analogy>
There's no excuse for using a web browser from 7 years ago. As long as you are using XP or later, IE 7 is easy to aquire and install, and is a much better browser for both the user and developer. Now, telling them IE sucks and they should go to firefox might be considered rude(if still good advice), but urging them to upgrade to the latest free version of the software they're using is not bad form. It's nothing but good for them to upgrade.
Note that Joost was a bittorent like if not bittorrent based streaming service, and it has now completed its switched to the in browser flash based model. Joost came before hulu, had more hype then hulu, but hulu still ate it's lunch. Granted, some of the reason is content, but some of it is the fact that people just prefer to use their web browser for everything these days. I preferred the quality when Joost was P2P, but the market has voted.
Slashdot Mirror
Try NOD32. The scanner that actually got top ratings in this test, for finding the highest number of viri without ungodly number of false positives. I've used it for a few years, and it's fast and has a good track record on virus tests. Can't recommend enough.
Solution 1: Install Firefox or Opera.
Solution 2: If you're not allowed to do that, you're also not supposed to be surfing Slashdot at work. Stop.
One machine, at least 2 monitors, and as much ram as you can afford.
With quad and octo core machines readily available, it's a no brainer. But go for the 64 bit version of your favorite OS and gobs of ram. A few hard drives in raid 5 or 10 always help. A great keyboard, mouse, and 3 monitors will complete the developers god box.
Really, CPUs are ridiculously fast, and it's all about the IO devices and memory today.
There is no new trust relationship; The parents simply sign the signing key. Exactly what trust can be inferred from that is independent of DNS.
There is a time in the roll-over where you have published a new key, but the old key is still cached. How does DNSCurve deal with this?
About new encryption options: Much like HTTP, DNSSEC can be extended by wherever both endpoints support. OS a new client would get fancy ECC encryption, and older DNSSEC capable versions would get RSA. Over time as people upgrade, RSA gets turned off. That's how compatibility works in the real world.
DNSCurve has some good design decisions, but there are many corner cases that DNSSEC solves that DNSCurve does not address. Still, given time it could be usable, but it's not that much better. DNSSEC deployment can be as easy if you like, offers the same level of protection against MITM attacks, and in general is good enough. You obviously don't think so, but the DNSCurve site pits the best possible deployment options for DNSCurve against the worst possible deployment senario for DNSSEC. DNSSEC can be plug-in simple also. The only real wins for DNSCurve are smaller packets today, and router compatibility. Its downsides are poor key management management and future upgrade path, and even if the tradeoff was worth it (which I don't believe it is), it's not worth throwing away the momentum DNSSEC currently has.
We all wish DNSSEC could be simpler, and if DNSCurve was really much easier to deploy for the same security, I'd be all over it. However, I don't believe it is. Good deployment tools exist for DNSSEC and many more will be created, but DNSCurve's security downsides in key management can't be automated away.
1. I have, it has the same attacks with the same problems. He redefines DOS attacks as simple forgery resilience, which DNSSEC also supports. DOS problems with DNS commonly seen are resource or network consumption issues, on the client, server, or as an amplifier of an attack against a 3rd party. DNSSEC and DNSCurve both do no affect any of these issues besides making them worse. But maybe I'm wrong; the specs suck and there's no implementation to play with. Give me an example where DNSCurve provides protection DNSSEC can't.
2. DNSSEC is extensible, and the hard work of protocol design is done up front. New encryption methods can be added and migrated in backwards compatible in stages, while to upgrade DNSCurve you'd need to design a whole new protocol. Yes, this does make converting to DNSSEC more difficult up front, but DNSSEC is a much better long term solution.
3. No, they are not. NSD is from scratch and the code is available in SVN to verify that. I'm not privy to all the details of the others but some of them do claim to be from scratch. Overall, it doesn't matter. Most (11) vendors support DNSSEC, can you point to one actual implementation of DNSCurve? How about 11 inter-operable implementations?
4. Yes, non-compliant routers are a problem, I admit. Not a large one, as I posit that before end users care about DNSSEC or have software that is requesting DNSSEC information, they will be replaced or upgraded. Windows 7 "pre-betas" which have been released have DNSSEC support, and will be the first end user systems to be compliant.
5-6. DNSCurve needs support all along the chain of trust to the root to be secure. DNSSEC needs support all along the chain of trust to the to root to be secure. Notice the similarity? There are a myriad of attacks against DNS, some where external parties force resolving of domains through various means (think image tags in HTTP). DNSSEC and DNSCurve have the exact same attack profile against all of these attacks.
The interaction between the parent and child is easier with DNSCurve, but because of this there is no way to roll over keys in a manner that doesn't break the security of the system. Otherwise they act the same way.
Main benefits of DNSCurve:
Crappy routers allow it to pass.
Some privacy protection given by encrypting transfers, though doesn't protect against traffic analysis.
Supports smaller ECC today.
Less complicated method of authenticating non-existence of domains.
Overall, less complicated.
Main benefits of DNSSEC:
Tested, secure, with design docs and very good specifications.
Widely implemented in software, though not yet widely deployed.
Allows for very strong key protection for high profile sites, or less security and more convience for low profile sites.
Uses time tested RSA, not a 2 year old ECC variant. Can later switch to ECC if desired.
Allows for rolling over keys in ways that do not break the trust relationship.
Allows for easily adding multiple encryption algorithms.
Overall, more flexible.
In terms of likelihood of deployment, DNSSEC is far ahead:
Mandated by US government and military for deployment in their networks.
Deployed by multiple ccTLDs.
Being tested at the root and reverse zones.
Multiple ISPs have public DNSSEC testbeds.
1. DNSSEC does in fact make DOS attacks worse in the very same ways DNSCurve makes DOS worse: Resource usage and bandwith. However, DNSCurve makes authoratative server computer useage worse, while DNSSEC does not. DNSSEC with RSA makes bandwith useage worse then DNSCurve with ECC, which is why DNSSEC will soon support ECC.
2. DNSCurve misses a lot of the extensibility and forward compatibility including ability to roll over keys, have offline signing, and switch to new crypto alogorithms. All those things are important to a long time secure DNS.
3.This is not true. Namesurfer Suite has both a BIND based and proprietary DNSSEC aware server, NLNET labs has NSD and Unbound, Xelerance and Nominum now supports dnssec, and many more. There's a nice chart of capabilities in this report on page 5 and 6, and more have been added since then.
4.This is a tool problem, and many tools are avalible and being made to make this simple.
5. This is false. True, the parents do not need to modified to accept DNSSEC KEY records like they do for DNSSEC, but the parents themselves must use DNSCurve, or the chain of trust is broken and the protection of that one link is meaningless. In both schemes, the parent must support the security standard to gain anything.
6.This is not true. The end-user needs the root key ahead of time, and then there is NOTHING a MITM can do to convince the client that the information shouldn't be signed. This sort of attack is why the chain of trust from the root is important, and similar to the reason why the NSEC or NSEC3 records must exist. DNSSEC provides much stronger resilience in the case of MITM then DNSCurve.
That is a policy decision not covered by the DNSSEC standards. He would have to do that for all traffic to the root and TLD servers for that attack to be affective, and you would have to be set up in a way that would allow unsigned root traffic as valid.
Which is to say, no, that attack won't work for any sane deployment.
DNSSEC support is in the current pre-beta releases of Windows 7, and I'm sure it will get added to their next server platform release also.
The requirement to sign all .gov domains by next year means MS has to support it or lose government support. Though personally I hope no government agencies are using MS DNS servers, that's a different rant...
Ah, DNSSurve seems to claim to protect against DOS attacks by a MITM. Honestly the MITM problem is the LEAST of the DOS attack problem, and there's no reason DNSSEC servers couldn't be trivially modified to behave the same way. In fact DNSSEC is silent on how to handle badly signed or corrupted packets, and that sort of DOS breaking capability is within the standards. The classes of DOS attack mentioned in RFC 4033 (resource and bandwidth consumption ) as well as the ability to use DNS as a DOS amplifier work the EXACT same way against DNSCurve. Perhaps I am missing something, but the DNSCurve docs are poor and incomplete and don't mention DOS anywhere but in that blurb.
Here's why the DNSCurve chart is a bunch of crap:
1) He attacks NSEC3 as already reversable. This is blatantly false, SHA-1 currently used is MUCH harder to reverse then simply querying the server. If SHA-1 fails, new signing algorithms can be used instead. The way that NSEC3 CAN be attacked is through a dictionary attack, and if you have dictionary words as DNS names, they can be recovered just as easily by brute-forcing the server. The protection is the same, as you only get a limited amount of NSEC3 records per query also, so server side protections against brute forcing DNS records would be the same sorts of protections against querying for all NSEC3 records.
2) He attacks DNSSECs use of 1024 bit RSA. DNSSEC does have RSA as the only manditory public key cypher, but it does NOT specify bitlength. 2048 bit keys as key signing keys are the likely length at first, and 1024 bit is just a strawman that doesn't exist in the specs. As already discussed, DNSSEC can be, and is in the process of being extended to use ECC or any other public key crypto.
Here's the case for why DNSCurve isn't good enough: DNSCurve REQUIRES that the signing key be online. DNSSEC can operate with the signing key online, and gets easy deployment on the server side. The only way it would be harder then DNSCurve is that you have to send your parent server a DNSKEY in addition to a glue record. It's still a copy paste on your side, but it does require your parent is DNSSEC aware.
Alternatively you can operate in off-line mode, where you have to do the signing offline on a non-connected machine, and copy the records back to the server. DNSSEC deployment dificulty is a tool issue, and there are a number of good deployment tools written that take the difficulty out of it. DNSCurve is simple by design, but not secure and not flexible. The only place it is more difficult in the parent-child relationship.
DNSCuve would have horrible political problems. DNSSEC is currently waiting on political, not technical issues. You think the current squabble over who holds the signing key is bad? With DNSCurve, you HAVE to put the signing key online at every root server. In DNSSEC, you have the root signing key in a hardware key holding box, and put armed guards around it. One of these is massively more secure then the other. If that root key is compromised, DNSSEC has ability to cleanly roll over to a new key with a prepublish scheme, DNSCurve do to its simplicity has no mechanism.
DNSCurve seems like a good idea due to its simplicity, but DNSSEC can have similar simplicity with the right tools, but also has the flexibility to adapt from that easy, low maintenance but less secure deployment to high-security and guys with guns deployment. DNSCurve fails because if its simplicity and inflexability
All in all, DNSCurve is where DNSSEC was 10 years ago, with a cool idea but not covering all the use cases needed. Sorry, but DNSSEC does what we need, and it does it now.
Remember: The recent DNS bugs were predicted over a decade ago. The BIND group said don't worry, we'll have DNSSEC done soon, but other DNS server vendors (all those not based on BIND) adopted the very simple method of being immune to them.
No one had simple ways of being immune. 2 vendors had the port randomization turned on, far from everyone not BIND. It was a smart hardening step, but it doesn't make them immune to the currently known attacks. If it did, we wouldn't be having this conversation.
I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.
DNSSEC is currently deployed live in multiple countries, .gov and .arpa are now signed (but only for testing purposes at the moment).
Yes, the number of DNSSEC hosts is only in the low 5 digits, but that's still way more then DNSCurve. 11 vendors have DNSSEC compatible DNS servers, which I believe is 11 more then DNSCurve. DNSCurve would have to be significantly
better in order to garner support at this stage, and I'm not seeing it.
DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.
DNSSEC is not.
This is a valid point. Only about 1/4 of recently tested home routers allowed DNSSEC traffic. It's also a problem that is trivial to solve in the long term. Once DNSSEC is deployed, routers will follow. Realistically however, all home routers will be DNSSEC capable before Windows can deal with the DNSSEC data. DNSSEC can still make policy decisions at the ISPs recursive resolver before that time however.
DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.
DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.
Strange that the link you send doesn't mention DOS attacks at all.
DNSSEC requires 0 more compute power, but does increase network traffic. DNSSEC can be extended to use ECC instead of RSA to reduce the network overhead, with NO computational overhead.
I don't think you know what you're talking about.
Oh? Read RFC 4034, then get back to me. Elliptic curve crypto already has a specified algorithm type, listed in appendix A.1. Unfortunately, the exact format hasnt been standardized yet. There are 245 more unassigned crypto specifications available for future use, I'd call that extensible.
DNSCurve does have some good ideas since it was designed to be easy to deploy, while DNSSEC deployment frankly sucks. DNSSEC is designed by committee,and it shows. On the other hand, it has many future-proof features like the ability to upgrade the crypto used in case RSA, DSA, ECC, or any other scheme falls like a house of cards, or simply need to be made longer in order to survive attacks.
If DNSCurve was proposed 5 years ago, it would have had a good chance of becoming the standard. Now, frankly, it's too late. Most of the major DNS servers support DNSSEC, .gov is currently signed and all US government sites must use DNSSEC by next year, the root servers and reverse .arpa domains have DNSSEC testbeds, Comcast has deployed their dnssec test servers. The political problems of who holds the root keys will be solved soon and DNSSEC will be live. Whether it takes off or not is a question for the market to decide.
Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.
DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.
It's hard to make a case for the need to protect the DNS traffic from sniffing, the threat is modification, not sniffing.
I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.
Comcast is currently running publicly available DNSSEC enabled testbed: http://www.dnssec.comcast.net/
.00001% of the Internet.
All the service providers are fed up with having to rush to patch all their DNS servers for a major break about once a year, and the time is right to convince them to switch after the largely publicized Kaminsky bug.
There are 2 major hold ups on DNSSEC adoption:
The root is not signed, and Microsoft doesn't support it.
Pretty much every other DNS server besides MS supports DNSSEC, and most now support the privacy preserving NSEC3 variant also.
Personally, I don't care if ISPs support it right away as I run my own recursive nameserver and avoid my ISPs like the plague, but I know that puts me in
DNSSEC *IS* fixing the bug.
It's a protocol problem, and needs a protocol level fix.
DNSSEC is an extension of the DNS protocol, and if any party in the transaction doesn't support it or ask for it, DNS still acts just like DNS. If the resolver asks for DNSSEC information, and the DNS server supports it, then you get the normal DNS information + the DNSSEC information.
This is NOT switching to a new platform, it's adding a signature to the existing platform for verification. It can work precicely because it is backwards compatible, and doesn't require everyone switch at once.
It DOES pretty much require a signed root, which is the primary hold up. However, at the moment there are countries where the top level domains are signed, and have a fairly good deployment of DNSSEC.
Not really hard, but it contains a fraction of the things available for Ubuntu or Debian testing, and seems to be more out of date also.
In the Ubuntu repositories I currently am using, there are 26K packages. Macports has 5k. Darwinports has 4k. Maybe they have the software and libraries you use, but they don't contain lots of things I use.
This is one of the major issues that keeps me on Linux.
Despite the fact you can get almost anything to run on OS X eventually, for most software it's much much harder to get up to date software versions then "apt-get install fizzbuzz" on Ubuntu or debian testing.
For my needs, Ubuntu is much closer to the "just works" ideal then OS X.
I vote developer issue.
The low-end mac mini hasn't had an update in years.
If you want to hook up and coming developers, you need a cheap platform to let them experiment on.
A mid tower would fit that much better then their current offerings. Of course, a newer mac mini would be a change in the right direction...
Compared to MS office, OO Writer is mostly as good as Word, and for me OO Calc is better then Excel, but Impress and Base still suck relative to their MS Office counterparts.
Impress is far too slow in rendering, to the point that I refuse to use it for any new presentations.
Instead I've found that LaTex Beamer and keyjnote do everything I want faster and easier.
Ubuntu isn't the great savior, but they did take the excellent Debian base and offered polish, support, and most importantly, marketing.
They've also forced other players such as Fedora to up their game in order to stay competitive.
All in all, Ubuntu has done good things for the Linux space, but still Linux market share is tiny.
For many nerds these days, at least among the security and programming nerds I hang out with, the competition isn't Linux/Microsoft anyway, it's Linux/Apple.
That looks like a nice homebrew gaming machine, but a really crappy laptop. That is NOT a usable keyboard.
Best Buy makes their money on cables and extended warranties. Never buy either at Best Buy.
They even have their own cable line for this purpose (Dynex).
And this is the difference.
High quality headphones work in the space you have, to get a great listening experience with speakers you need a new house built around your listening space..
There is a middle ground, I often listen to my Grado headphones with the speakers off and my subwoofer on for the full experience.
Care to post support for that statement?
FF w/ tracemonkey beats everything else in most benchmarks I have seen yet in pure javascript tests.
Safari and Chrome beat Firefox 3.1 sometimes in DOM heavy tests, but I've yet to see a benchmark where Opera beats FF 3.1 W/ or without the new "tracemonkey" VM enabled.
See:
http://ejohn.org/blog/javascript-performance-rundown/
For one counter example that popped in my head.
Wrong.
HTML 4.01 compliant would pass as compliant in this test. Heck, even valid HTML 2 or 3.2 would be compliant.
What this survey says is that 96% of webpages have at least one non-standard element included, or other violation of the standards.
I'd be interested in seeing a more detailed breakdown on the reasons: If a page is 99% standards compliant with one non-standard element for telling the browser not to store the password(for example, reddit.com), that's a lot different from badly nested and missing tags, etc.
I write and use security tools that parse HTML, and getting them to correctly handle all the poorly formed HTML out their is an absolute b*tch. Even libraries like beautifulsoup that are supposed to handle that still miss and break on a lot of input that modern web browers accept.
I can't tell you how much easier full XHTML compliance would make my work, but even valid HTML 4.01 would be a FAR improvement over what passes for websites out there.
Unfortunately, even my employers site is not valid HTML of any sort either... That wasn't one of the qualifications of the system that was chosen, instead ease of use of the system was the qualifier. It claims to be XHTML transitional, but does not validate.
The good news is that standards compliance is on the rise. They included this table, showing % compliance found in their survey and similar surveys in the past:
Parnas Dec 2001 0.71%
Saarsoo Jun 2006 2.58%
MAMA Jan 2008 4.13%
They also found that 33% of pages used flash! Really? Noscript has kept me from noticing that I guess..
Lets say I'm a road builder, and I know your 2001 Microsoft Road Explorer sucks and would cause me many hours of work to work around it's bugs.
Lets say I decide I'm not planning on doing that extra work in my future roads, and I put up a sign telling you that your car is faulty and you should go to your dealer for a FREE safety and functionality upgrade.
It's hard to argue that that is a bad thing to do.
</car analogy>
There's no excuse for using a web browser from 7 years ago. As long as you are using XP or later, IE 7 is easy to aquire and install, and is a much better browser for both the user and developer.
Now, telling them IE sucks and they should go to firefox might be considered rude(if still good advice), but urging them to upgrade to the latest free version of the software they're using is not bad form. It's nothing but good for them to upgrade.
Note that Joost was a bittorent like if not bittorrent based streaming service, and it has now completed its switched to the in browser flash based model.
Joost came before hulu, had more hype then hulu, but hulu still ate it's lunch.
Granted, some of the reason is content, but some of it is the fact that people just prefer to use their web browser for everything these days.
I preferred the quality when Joost was P2P, but the market has voted.