The alternatives have not-so-subtle incompatibilities with BIND and existing practice, are not proven in the field, or are unmaintained by the original developer. In fact, BIND is often deliberately incompatible with its previous versions, so it shouldn't be too hard to beat it in this area, but apparently it is.
tinydns, which was mentioned by the story submitter, is unmaintained, like most (if not all) software that Mr Bernstein has ever released. (This is especially problematic because Mr Bernstein refuses to license the software for a fork.) It does not even compile on modern systems, and it uses a non-standard zone file format. In the days of BIND 4 and BIND 8, all that pain was probably justified, but with BIND 9, things are rather different.
In my experience, in the area of caching full resolvers, BIND 9 simply lacks serious competition, feature-wise, and in terms of ease of administration and interoperability. For authoritative-only servers, RIPE's nsd is an alternative, but BIND 9 is typically not such a big trouble that running two different name servers is really needed.
Hence general-purpose PCs and bigger embedded systems are safe from this, but small devices such as handhelds are vulnerable?
No one is vulnerable, only the unwary who don't read Slashdot. This patent is quite specific and easy to work around. It's not mouse-related at all, too. Of course, it's a user interface patent and, as such, rather bad in itself, but on the total obnoxity scale, it scores a pretty low value.
Most digital copiers can do similar things nowadays. Typically, you rent such machines, and it's not too expensive in this case, especially if the device is also used as a true copier.
I'd rather like to see browsers that can handle SVG natively first. Plugins don't count because of their operational problems. (Automatically deploy a security update for a plugin from Adobe? Good luck!)
This is the bit I don't understand about Quantum crypto - if conventional crypto is broken then there's no way for Bob to be sure Alice is at the other end and vice versa, so breaking quantum cyrpto becomes as easy as cutting the fiber and talking to both ends.
In theory, you could detect that fiber cut and act accordingly, but you don't need quantum cryptography for that. If you run a simply key exchange protocol (DH is probably enough), you are safe from passive eavesdropping (which might be possible by bending the fibre, without cutting it). Message insertion and deletion on an intact fiber link is probably too complicated to be feasible.
So by relying on conventional crypto, quantum crypto is exactly as weak as conventional crypto yet requires costly and inflexible infrastructure, why are people bothering with it at all?
First, it's a cool research topic. Second, there are now a few startups which want you to buy their products. Most of the quantum cryptography news during the last few months was generated by such startups, and they certainly won't tell you all the caveats.
Second, QKD is unconditionally secure, and that includes man-in-the-middle.
Which QKD protocol are you talking about?
For example, the proof of security for BB84 QKD by Shor and Preskill does not explicitly state the threat model, but it apparently does not include full man-in-the-middle attacks which may hijack all channels. Thus, the obtained result is considerably weaker than what we expect from conventional cryptography (which should protect against MITM attacks, too).
Rats don't have a union and get paid 1/10th the food dogs do...
Right now, local children are used instead. Storing some sweets is probably cheaper than transporting those rats, so there is little incentive to stop that awful practice.
The point isn't to use the quantum entanglement to directly pass information back and forth; rather it is to distribute a key for a one time pad.
There is no such things as "a key for a one time pad". The one time pad is the key. The needed part of the pad is also as long as the message itself, so you can't save anything by transmitting the pad excerpt instead of the message itself.
The aim is to produce a communication system that cannot be intercepted by anyone
"Passively intercepted", not "intercepted". Active interception is still possible. And please keep in mind that quantum cryptography is not end-to-end. Service providers at both ends of the transmission (and intermittent service providers if there is no direct fiber) can easily eavesdrop, too.
Actually, quantum cryptography would be a huge step backwards, away from cryptography for the masses.
Quantum cryptography has a cool name, but in practice, it sucks, at least its current implementations. It's not end-to-end by design (you can't have a direct fiber to everyone you want to communicate with these days, after all), and so it's easily regulated. It's expensive. It doesn't solve key management problems, and the installations that have been publicly described so far are extremely vulnerable to man-in-the-middle attacks.
If I believed in conspiracy theories, I'd say that the NSA is luring the EU towards unavailable and untested quantum cryptography, and away from commercially available, tested, reliable and rather secure conventional crypto products. Actually, the quantum crypto recommendation (whether it's contained in some EU documents or not) is the result of a pretty slick PR (and lobbying) campaign.
Microsoft will mail you a CD, for free, of the most recent updates and service packs.
In this case, "most recent" means "October 2003". (This for the German version, I receive an error message when I try to order US English version.) Obviously, "October 2003" doesn't help that much. The LSASS exploit is probably the most important one that is missing.
Since a few people have mentioned this: He was using Windows 2000. It doesn't have a firewall.
There are some crude filters which cannot even handle DNS (but they would have worked against those 445/TCP worms). To some extent, IP Security Policies help as well. They just can filter some kinds of traffic. 8-(
Different pairs of keys have different timings, so just looking at the timing difference gives you quite a bit of information. There's even a paper about this phenomenon which gives some numbers. It focuses on sniffing the network traffic, but the results should also apply for data that is gather accoustically.
It is just an Internet-Draft (ID), that has been submitted for IETF approval. The IETF haven't reviewed it yet, nor taken a position on whether it should be a standard or not.
It won't become a standard because of severe technical defects anyway. The proposal only addresses a few quirks in the TCP state machine. If we go that way, the IETF will have to issue a TCP security fix RFC twice a year, as soon as new issues in the state machine surface. This is not acceptable. Rolling out a TCP upgrade twice a year causes unacceptable costs.
I could submit a ID for a protocol for standing on my head. That doesn't mean it is an IETF recommendation or that it will be.
Strangely enough, this draft is a Working Group submission (although it obviously wasn't discussed in the WG before because of NDAs etc.), so it's considered slightly more important than your individual submission.
It would be interesting to work out how much a company would save using free OSS over existing solutions (think OpenOffice vs. MS Office) and how much employee time that would equate to that could then be donated back to the community.
If you want to use OSS successfully, you must give back to the community. If you keep your local tweaks and patches to yourself, you'll have to reapply them after every upgrade. I've done that, and even with version control, it becomes quite painful after some time and involves just too much job security for the local patch master.
One percent donated to community projects translate to 30 minutes per week, at most. This is actually very little compared to the time people spend on community projects in which they actively participate. I don't think this is sufficient if you want to send the message that your company is socially responsible.
Once more, the link between illegal copies and Windows Update has been made. Many people believe that these updates are the only way Microsoft could tell that they run some illegal copies.
A few of them will refuse to use online updates because they fear that it might reveal their illegally obtained software copies to Microsoft or the BSA (not Windows, Windows is quite hard to pirate these days because it's so ubiquitous, but full Microsoft Office, and other BSA software).
More details at: http://www.lurhq.com/phatbot.html
Note that Phatbot, as described on the page above, is mostly a failed experiment. That version uses WASTE to create the botnet, which is far less scalable than IRC. WASTE simply wasn't designed for the large number of clients typically in a single botnet.
Apart from that, Agobot/Phatbot/Gaobot (or what's it called today) is fairly nasty. Some early reports from March quote numbers which suggest that between one and two million hosts have been compromised, and the bot still very active.
No, Phatbot (or Agobot, which seems to be the more correct name) is NOT a Sasser derivative. Recent Agobot version were extended for attacking Microsoft Windows machines using the same LSASS defect, but this doesn't make Agobot make a derivative of Sasser.
Calm down, it's just vaporware at this point, and computing will be affected.
If finished, this technology will deny those who refuse to use non-free software access to many aspects of mainstream culture, but this doesn't seem to be a great loss to me.
A couple of years ago, most vendors certified their Java software just for selected Sun JVM versions. This meant that most serious Java users had to install different JVM versions on their systems. In a sense, Sun had already fragmented Java on its own.
Has this changed in the meantime? Is Sun's Java implementation fully backwards compatible now, and do other vendors trust Sun in this area?
Critical exploits in BIND 9 still have to show up. The really nasty bug so far was actually in OpenSSL.
It's not clear why people continue to use BIND.
For the full resolver part, their are hardly any alternatives. If you need DNSSEC, your options besides BIND are even more limited.
tinydns is unusable for most people (who aren't masochists) because it doesn't conform to existing standards and parctice. Just speaking the DNS protocol is not enough, you also have to implement some of BIND's quirks, and more important: the software has to be maintained. DNS is still evolving, DJB's software is not. (Some of it doesn't even compile on modern, POSIX-conforming systems.)
Yeah it's been a bad week for Cisco but they aren't Microsoft. They won't ignore these problems.
Not quite true. Their IPsec extension called XAUTH has got the same problems, and and these have been ignored for years:
http://www.ima.umn.edu/~pliam/xauth/
There's a recent rediscovery of the problem archived at: http://www.securityfocus.com/archive/1/347351
The only reason to buy Cisco after all [...] is for the support.
Exactly, and that's why it's sometimes so painful to be a Cisco customer. You have to buy more of their products, or you will lose support guarantees for existing products. And you need these guarantees if you are implementing highly experimental technologies such as QoS and VoIP on production networks, or it's your fault if things break (even if it's an IOS bug).
At least hardly anybody has Microsoft support contracts, so using different products where it makes sense is often a very desirable option because you can't lose that much.
Slashdot Mirror
The alternatives have not-so-subtle incompatibilities with BIND and existing practice, are not proven in the field, or are unmaintained by the original developer. In fact, BIND is often deliberately incompatible with its previous versions, so it shouldn't be too hard to beat it in this area, but apparently it is.
tinydns, which was mentioned by the story submitter, is unmaintained, like most (if not all) software that Mr Bernstein has ever released. (This is especially problematic because Mr Bernstein refuses to license the software for a fork.) It does not even compile on modern systems, and it uses a non-standard zone file format. In the days of BIND 4 and BIND 8, all that pain was probably justified, but with BIND 9, things are rather different.
In my experience, in the area of caching full resolvers, BIND 9 simply lacks serious competition, feature-wise, and in terms of ease of administration and interoperability. For authoritative-only servers, RIPE's nsd is an alternative, but BIND 9 is typically not such a big trouble that running two different name servers is really needed.
Hence general-purpose PCs and bigger embedded systems are safe from this, but small devices such as handhelds are vulnerable?
No one is vulnerable, only the unwary who don't read Slashdot. This patent is quite specific and easy to work around. It's not mouse-related at all, too. Of course, it's a user interface patent and, as such, rather bad in itself, but on the total obnoxity scale, it scores a pretty low value.
Most digital copiers can do similar things nowadays. Typically, you rent such machines, and it's not too expensive in this case, especially if the device is also used as a true copier.
I'd rather like to see browsers that can handle SVG natively first. Plugins don't count because of their operational problems. (Automatically deploy a security update for a plugin from Adobe? Good luck!)
This is the bit I don't understand about Quantum crypto - if conventional crypto is broken then there's no way for Bob to be sure Alice is at the other end and vice versa, so breaking quantum cyrpto becomes as easy as cutting the fiber and talking to both ends.
In theory, you could detect that fiber cut and act accordingly, but you don't need quantum cryptography for that. If you run a simply key exchange protocol (DH is probably enough), you are safe from passive eavesdropping (which might be possible by bending the fibre, without cutting it). Message insertion and deletion on an intact fiber link is probably too complicated to be feasible.
So by relying on conventional crypto, quantum crypto is exactly as weak as conventional crypto yet requires costly and inflexible infrastructure, why are people bothering with it at all?
First, it's a cool research topic. Second, there are now a few startups which want you to buy their products. Most of the quantum cryptography news during the last few months was generated by such startups, and they certainly won't tell you all the caveats.
Second, QKD is unconditionally secure, and that includes man-in-the-middle.
Which QKD protocol are you talking about?
For example, the proof of security for BB84 QKD by Shor and Preskill does not explicitly state the threat model, but it apparently does not include full man-in-the-middle attacks which may hijack all channels. Thus, the obtained result is considerably weaker than what we expect from conventional cryptography (which should protect against MITM attacks, too).
Rats don't have a union and get paid 1/10th the food dogs do...
Right now, local children are used instead. Storing some sweets is probably cheaper than transporting those rats, so there is little incentive to stop that awful practice.
The point isn't to use the quantum entanglement to directly pass information back and forth; rather it is to distribute a key for a one time pad.
There is no such things as "a key for a one time pad". The one time pad is the key. The needed part of the pad is also as long as the message itself, so you can't save anything by transmitting the pad excerpt instead of the message itself.
The aim is to produce a communication system that cannot be intercepted by anyone
"Passively intercepted", not "intercepted". Active interception is still possible. And please keep in mind that quantum cryptography is not end-to-end. Service providers at both ends of the transmission (and intermittent service providers if there is no direct fiber) can easily eavesdrop, too.
Actually, quantum cryptography would be a huge step backwards, away from cryptography for the masses.
Quantum cryptography has a cool name, but in practice, it sucks, at least its current implementations. It's not end-to-end by design (you can't have a direct fiber to everyone you want to communicate with these days, after all), and so it's easily regulated. It's expensive. It doesn't solve key management problems, and the installations that have been publicly described so far are extremely vulnerable to man-in-the-middle attacks.
If I believed in conspiracy theories, I'd say that the NSA is luring the EU towards unavailable and untested quantum cryptography, and away from commercially available, tested, reliable and rather secure conventional crypto products. Actually, the quantum crypto recommendation (whether it's contained in some EU documents or not) is the result of a pretty slick PR (and lobbying) campaign.
Microsoft will mail you a CD, for free, of the most recent updates and service packs.
In this case, "most recent" means "October 2003". (This for the German version, I receive an error message when I try to order US English version.) Obviously, "October 2003" doesn't help that much. The LSASS exploit is probably the most important one that is missing.
Since a few people have mentioned this: He was using Windows 2000. It doesn't have a firewall.
There are some crude filters which cannot even handle DNS (but they would have worked against those 445/TCP worms). To some extent, IP Security Policies help as well. They just can filter some kinds of traffic. 8-(
Different pairs of keys have different timings, so just looking at the timing difference gives you quite a bit of information. There's even a paper about this phenomenon which gives some numbers. It focuses on sniffing the network traffic, but the results should also apply for data that is gather accoustically.
It is just an Internet-Draft (ID), that has been submitted for IETF approval. The IETF haven't reviewed it yet, nor taken a position on whether it should be a standard or not.
It won't become a standard because of severe technical defects anyway. The proposal only addresses a few quirks in the TCP state machine. If we go that way, the IETF will have to issue a TCP security fix RFC twice a year, as soon as new issues in the state machine surface. This is not acceptable. Rolling out a TCP upgrade twice a year causes unacceptable costs.
I could submit a ID for a protocol for standing on my head. That doesn't mean it is an IETF recommendation or that it will be.
Strangely enough, this draft is a Working Group submission (although it obviously wasn't discussed in the WG before because of NDAs etc.), so it's considered slightly more important than your individual submission.
It would be interesting to work out how much a company would save using free OSS over existing solutions (think OpenOffice vs. MS Office) and how much employee time that would equate to that could then be donated back to the community.
If you want to use OSS successfully, you must give back to the community. If you keep your local tweaks and patches to yourself, you'll have to reapply them after every upgrade. I've done that, and even with version control, it becomes quite painful after some time and involves just too much job security for the local patch master.
One percent donated to community projects translate to 30 minutes per week, at most. This is actually very little compared to the time people spend on community projects in which they actively participate. I don't think this is sufficient if you want to send the message that your company is socially responsible.
Once more, the link between illegal copies and Windows Update has been made. Many people believe that these updates are the only way Microsoft could tell that they run some illegal copies.
A few of them will refuse to use online updates because they fear that it might reveal their illegally obtained software copies to Microsoft or the BSA (not Windows, Windows is quite hard to pirate these days because it's so ubiquitous, but full Microsoft Office, and other BSA software).
More details at: http://www.lurhq.com/phatbot.html
Note that Phatbot, as described on the page above, is mostly a failed experiment. That version uses WASTE to create the botnet, which is far less scalable than IRC. WASTE simply wasn't designed for the large number of clients typically in a single botnet.
Apart from that, Agobot/Phatbot/Gaobot (or what's it called today) is fairly nasty. Some early reports from March quote numbers which suggest that between one and two million hosts have been compromised, and the bot still very active.
No, Phatbot (or Agobot, which seems to be the more correct name) is NOT a Sasser derivative. Recent Agobot version were extended for attacking Microsoft Windows machines using the same LSASS defect, but this doesn't make Agobot make a derivative of Sasser.
Calm down, it's just vaporware at this point, and computing will be affected.
If finished, this technology will deny those who refuse to use non-free software access to many aspects of mainstream culture, but this doesn't seem to be a great loss to me.
A couple of years ago, most vendors certified their Java software just for selected Sun JVM versions. This meant that most serious Java users had to install different JVM versions on their systems. In a sense, Sun had already fragmented Java on its own.
Has this changed in the meantime? Is Sun's Java implementation fully backwards compatible now, and do other vendors trust Sun in this area?
How does it compare to APUE?
The offical project website with pics progress reports et al.
Does this mean that there wasn't any progress since 2002? And they haven't done any testing yet to check that the technology actually works?
Exploits are not uncommon in BIND, even today.
Critical exploits in BIND 9 still have to show up. The really nasty bug so far was actually in OpenSSL.
It's not clear why people continue to use BIND.
For the full resolver part, their are hardly any alternatives. If you need DNSSEC, your options besides BIND are even more limited.
tinydns is unusable for most people (who aren't masochists) because it doesn't conform to existing standards and parctice. Just speaking the DNS protocol is not enough, you also have to implement some of BIND's quirks, and more important: the software has to be maintained. DNS is still evolving, DJB's software is not. (Some of it doesn't even compile on modern, POSIX-conforming systems.)
Yeah it's been a bad week for Cisco but they aren't Microsoft. They won't ignore these problems.
Not quite true. Their IPsec extension called XAUTH has got the same problems, and and these have been ignored for years:
http://www.ima.umn.edu/~pliam/xauth/
There's a recent rediscovery of the problem archived at: http://www.securityfocus.com/archive/1/347351
The only reason to buy Cisco after all [...] is for the support.
Exactly, and that's why it's sometimes so painful to be a Cisco customer. You have to buy more of their products, or you will lose support guarantees for existing products. And you need these guarantees if you are implementing highly experimental technologies such as QoS and VoIP on production networks, or it's your fault if things break (even if it's an IOS bug).
At least hardly anybody has Microsoft support contracts, so using different products where it makes sense is often a very desirable option because you can't lose that much.