We've known since the beginning that the security of RSA depends on the key length that computers can factor using the latest algorithms. 10-bit keys were always too short; 512-bit keys were cracked in 1999, and Shamir ("S" in "RSA") published work in 2003 suggesting that 1024-bit keys might be endangerable soon - they're probably fine for one-shot use on any individual message less important than planning the overthrow of a large government, and they're certainly fine for bank transactions, because the cost of breaking them far exceeds the amount of money in your bank account. But for a single long-term hard-to-change widely-used target, like the DNS root or.com, RSA1024 is pretty dubious. It's probably fine for signing www.yourdomain.com unless your domain is a large bank, but the protocol needs to support keys that are long enough for everybody, which means it needs to be 2048 or longer.
Unfortunately, DNS has fairly tight constraints on how many bits you can cram into a transaction, and 2048 bits isn't very practical. ECC uses much shorter keys, and while 160 bits isn't quite long enough, 255 appears to be really good, unless some improvement in the theory changes that.
But yeah, elliptic curve theory is a lot newer than factoring theory, and the risk of a theoretical breakthrough is a lot higher, though Moore's Law isn't much of a threat for a while. On the other hand, DNScurve uses ECC for transactions, not for long-term signatures, so there isn't the same One Big Target effect, since every DNS server is using its own different key.
Most copper looks like one of two things - pipes of a few standard diameters, or wires of a few standard gauges. A pile of M pieces of N-foot lengths of 1-inch pipe looks the same whether you just bought it or stole it from somebody, and if you're dealing with obviously-used pipe, you can chop it up into different lengths than the original (assuming you didn't already do that as part of the process of ripping it out of the house...) No foundry required.
If copper wire dealers wanted to get fancy, they could put serial numbers on wire reels, to make it a little less untraceable when you're selling "some wire left over from a building job", but they're not going to serialize the wire. I suppose a contractor could randomly spraypaint the stuff when installing it, which'd at least make it look obviously used, but again, a foundry isn't needed.
And you can always let the stuff hang around in your garage or your cousin's junkyard for a few months if you need to anonymize it a bit more, though that's more of a trick for professional thieves than amateur meth-heads.
There are three basic numbers of gTLDs we can support - a few, a few hundred to few thousand, and near-infinite.
Right now we've only got a few, which means that policies are relatively rigid and relatively enforced, and there's not much innovation except at or below 2LD..museum is about the only gTLD doing anything technically interesting, and otherwise it's just pricing and market segmentation (plus a few leftovers run by the US Government, mostly chaotically.) If you want to innovate, it'll cost you a few hundred thousand dollars and a year of begging ICANN to take your money and not add too many constraints.
Near-infinite would be a waste; you could just as well pile everything under.com.
But the intermediate range is interesting, because it's small enough to still be manageable and memorable, but large enough to have some diversity in how people manage domains. For instance, how do you resolve conflicts for a domain, other than first-purchaser with UDRP lawsuits? Maybe it'd make sense to have everybody who wants example.mytld to have a subdomain under it, with index.example.mytld explaining that sanjose.joesrestaurant.mytld is the one at 301 First St, while marin.joesrestaurant.mytld is the one on highway 101 in Marin? They've both got equal claim to any trademark on the name (and remember that the only IP that ICANN cares about is Intellectual Property), so why not give them equal treatment? Certainly for a personal-name kind of tld an approach like that might make sense, since there's a lot more name collision.
There are organizations that'll want to register under every new TLD, and other organizations that won't care, but if there are a hundred gTLDs, people will increasingly not care. (I'm surprised anybody who bought a.biz name when they were new would bother renewing it these days - too much spam and junk.) On the other hand, ICANN has the monopoly on the space, so they don't want to let the price drop unless they'll get really high volume - 20-50 gTLDs at $100K each make more money for less work than 1000 gTLDs at $1000, but maybe there's a market for 1000 of them at $10K.
The Marines are using the domain name marines.com in addition to marines.mil. Obviously this means they're in commercial business - attacking countries for hire, etc. Appalling, but at least under the Bush Administration they're willing to admit it. (Actually it's mostly a recruiting site, because they're trying to hire people who don't know to look under usmc.mil or marines.mil:-)
Go read the RFCs for DNS and look at the packet format picures- if you were writing DNS from scratch, that'd be an obvious thing to change (though I'd recommend 128 bits.) But the Transaction ID isn't one of the fields that you get to pick a size for, or one of the record types that you can replace with a newer record type such as IPv6's AAAA records instead of IPv4's A records or the various record types that DNSSEC uses. It's one of the early fields in the packet, always the same size, always 16 bits. Fixing that would require rolling out a whole new version of all the DNS tools in existence, and that's probably harder than getting IPv6 deployed.
What the fixes do is to also use the UDP port number that the query comes from for verification, so your DNS resolver won't accept a response for www.example.com on port 12345 unless it sent the request on that port (many DNS implementations used to send all the requests from UDP 53, and it made firewalling easy.) This was especially easy to implement, because DNS servers already send the response to the port where the request came from, so it only required changing the client end.
The fixes still aren't enough - an attacker now needs to send ~2^24 attack packets, since the transaction ID can still be birthday-attacked, but it's a lot safer the older versions where ~2^8 packets was enough. So we still need something extra, and DNSSEC solves a range of other problems.
Yes, there were some DNS systems that randomized port numbers already, so they're safe against birthday attacks on the 16-bit ID. DJB's obsessively careful, and at times like this it shows. But the ID's still only 16 bits long, and port numbers only get you another ~16 bits, so a ~2^24 packet attack can still succeed. That's not always going to work, but attackers don't have to win every time to be dangerous - they don't need to attack your account at your bank, as long as they can rip off somebody's account at some bank.
There are two basic approaches to fixing the problem - make the transaction ID enough longer that it can't be spoofed, or add a separate signature mechanism like DNSSEC. The first approach is unrealistic, because you'd need to deploy a new version of the DNS protocol, not just new implementations (even IPv6 keeps the same DNS version and transaction ID, and just adds more record types, which DNS is designed to support) - so good luck with that. The second approach has its difficulties as well, and there are other ways that digital signatures could be added, but DNSSEC is the closest to deployable that we've got.
Kaminsky wasn't an unknown - he'd spoken at a couple of Codecon conferences, doing increasingly heinous things to DNS. One year it was tunnelling SSH over DNS, which lets you break out of any firewall you're behind (and potentially lets malware do the same.) Another year it was the video-over-DNS hack referred to in the article. Codecon's not a big conference, but it's had a lot of high-quality presentations, and when I saw the announcement that Kaminsky had found a serious problem, it had to be more serious than merely breaking through firewalls...
DNS has two things that identify a UDP request - the transaction ID and the request's port number. 16 bits of ID seemed like plenty back in 1983, and many DNS versions didn't randomize the port number (since it's easier to just use 53 both ways through your firewall) before Kaminsky forced them to fix it. By requesting lots of bogus subdomains, you can birthday-attack the system, so you need ~256 guesses instead of 65536, and it's a lot easier to win that race against a real query.
But even the port-number fixes don't get you solid protection - they just raise the attack difficulty by a factor of a few thousand, so the attacker has to be a bit more determined. But an attacker doesn't need to be successful on every target or every DNS server to make money - there are lots of banks, and lots of users, and sending a few billion packets costs less than the amount he can steal if he's successful.
Changing the protocol would work just as well as deploying DNSSEC - a 128-bit ID would protect against birthday attacks - but that'd be much harder to get deployed. The port-number-randomization approach is at least a stopgap.
A few things have changed since my 2003/. post which I've attached below, but the main difference is that Kaminsky's attack has made people realize that DNSSEC matters, and that it's time to get the ICANN and Department of Commerce to sign the root and have the registries sign.com and other major domains. (It's fun watching the Feds panic about it, because much of it's their fault.) And while widespread IPv6 deployment is closer, IPv6 DNS just uses the same packet format as IPv4 DNS with some new record types, so it has the same vulnerabilities.
=============== Political Problems with DNSSEC =====
Some of the problems with DNSSEC are technical - most of them have to do with making things fit inside 512-byte packets and not breaking too many server implementations. But the big problems have been political, including politics implied by the protocol structure and politics that's separate from it.
Old US Fed Attempts to Stifle Crypto - Back in 1993, when DNSSEC was drafted, the US government was still doing the Cold War thing of pretending that there were Commies who shouldn't be allowed to have Crypto because their Spies could send Unbreakable Messages, and the FBI was encouraging them to maintain this charade because crypto might make illegal wiretapping difficult and mass wiretapping expensive. So Open Source publishing of DNSSEC code on the Internet or export to other countries was threatened by all the rest of the anti-crypto Export Law stuff, even though it only needed digital signatures and not encryption - because RSA digital signature code is also usable as encryption code, and because good digital signatures make forgery impossible. At one point, John Gilmore got approval for exporting a "bones" version of DNSSEC (with the crypto code removed) and then the approval got yanked shortly afterwards, in spite of their being no adequate legal justification for it. DNSSEC was pretty much stillborn because of those politics, which was too bad because we could have had a DNSSEC in place when the Web thing was taking off.
Hierarchical Nature of DNS - For many security and political applications, a hierarchy is a Bad Thing, because it means that somebody's in charge, and that there's one big weak point to attack it with. That doesn't seem to be much of a problem for DNSSEC, because it's piggybacking on DNS, which is inherently hierarchical. Sure, there's all that ugly politics about who gets to sell the name example.com and who gets to resolve conflicts if multiple companies want to be the One True Owner of the domain name example.com, but getting the folks who manage official assignment of the name example.com to sign the DNS record is a simple technical implementation, just as getting them to put the IP address in the DNS server is - it's *much* simpler than getting them to send the bill or the renewal notice correctly.
ICANN Ugliness - Of course, all this was mired in political ugliness, and the ICANN Name Gods fundamentally weren't interested in doing the right thing technically - they were interested in doing the power-grab thing on the intellectual property trademark space, not in technical administration. And the people who fight about name space ownership and collect your registrar money aren't really the people who run the physical root and.com DNS servers, many of whom worked for organizations funded by the US Government, who weren't going to push for crypto protection.
Multiple Name Registrars, Single Keys - There's a big ugly gap in the DNS hierarchicalness, which is that multiple registrars can sell you the name example.com, but there's only one DNS Signature Key for.com - does that mean that 50 random companies around the world can all be trusted to own those keys and not leak them? Fat chance! But the protocol wasn't designed for that kind of sharing.
Yes, Engineers understand math, at least to some extent. (I was surprised in grad school about how much more rigor was possible compared to doing the same material as an undergrad or high school student:-) And some kinds of engineers use appropriate math for what they're doing. Dijkstra's arguing here that software engineers generally don't. Sure, we'll occasionally apply order-of-magnitude math to our algorithms, deciding whether an N**2 or NlogN is a better choice for the size of data we're dealing with, but computer scientists have been bitching about the lack of use of program-correctness proofs for at least a decade before Dijkstra's talk, and even though our computers are 4 orders of magnitude faster and 6 orders more price-performing than when he wrote the talk, we still consider that stuff too inefficient for practical use and write lots of buggy code.
A simpler example than proof-of-correctness is input validation. A program is designed to take a given set of input and produce corresponding outputs, so one way to improve program correctness is to start by specifying the input set and validating whether the input the program receives is in that set and reject it if it's not. (Replaces "Garbage In Garbage Out" with "Garbage In Error Message Out".) My CS100 professor emphasized that ~30 years ago and made us run all of our homework programs on maliciously designed input, but how many of the security bugs you see today are still buffer overruns or stack smashing or other because people aren't bothering to define and enforce the valid input sets. It's improved a bit with object-oriented programming because objects are a bit more restrictive in what kinds of input they'll accept, and many of the popular objects validate their input and are almost as easy to use as similar objects that don't, as opposed to rolling your own lazily or using C's getwhatevers().
I partly blame Knuth for this:-) His books were the canonical algorithm books for a generation, and did the math really really well, but did programming examples in a baroquely ugly assembler language or spaghetti-pseudocode when better languages were available (e.g. Algol or cleaner assemblers), and that made it hard to learn how to apply his mathematical techniques to real programming.
Unfortunately, Ballmer's current cunning plan, Vista, hasn't worked out:-) The next cunning plan, V7, probably won't do worse, and maybe will do better, but by around XP time the CPU people had pretty much outrun MS, and the RAM people have also gotten ahead of it even with DDR or certainly by DDR2. One thing I'm missing by not doing Vista is the cache-on-flash feature, which is too bad; it'd let my disks spin down most of the time.
The other traditional driver for the CPU makers has been gamers, who can use all the power they're given, but the last few rounds that's mostly been in the graphics board camp, not the CPU camp; we'll see if the CPU side starts integrating more graphics functions or if the game companies increasingly leave PCs for consoles. (I'm not the target audience for that; I'll probably continue using mobo-builtin graphic unless my next LCD flatscreen needs a different interface, in which case I'll buy a =$49 board, and Nethack never did need all that DirectX anyway:-)
There's only so much spectrum out there, especially if they use longer-wavelength systems which get better distance and penetration and therefore have more users per chunk of bandwidth. So it's going to have a lot less average bandwidth per user than wired systems, regardless of what the airspeed of any given connection might be. That's going to annoy the kinds of people who gripe about Americans having a lot less bandwidth than [cliche]old people in Korea[/cliche], and it's not going to handle BitTorrent or streaming video downloads reliably, but it'll probably beat modems and text messaging.
Yes, there's a Social Security Trust Fund that's invested in T-bills. That just means that they've taken any surplus they had in the past and lent it to the Government, which spent it, and which promises to tax people in the future to pay it back. So when all of us Boomers start retiring and not dying off quickly enough, not only will the Social Security Tax on working people not be enough to cover the costs, but the Feds will have to start running a budget surplus to pay off the debt, instead of continually borrowing more like they did while we were working. So it's going to suck to be young and working, or old and collecting taxable interest on our savings.
Before Bush took power, we had a $5T national debt, because previous administrations didn't have the financial discipline to not run deficits even during boom years. Bush's Fiscally Responsible Small Government Republicans doubled that before the Crisis, and it looks like they're spending another $5T-10T on bailouts (though ostensibly they'll get some of that back.) The current total debt is about 1 US GDP, or about $50K/American.
And to the extent that us older people saved money in forms other than houses (oops), we'll be getting lower interest rates on what we saved than what I'd been planning on, because more of us will be competing to invest it in whatever businesses the younger people who are working are running. So it's going to suck to be old and not working. And because it's also going to suck to be young and working, those people aren't going to be buying $5 coffees that much, and Walmart only needs so many greeters, so obvious old-people jobs are going to be scarce.
From a legal perspective, wiretapping to listen to the audio of a call is more more serious than looking at the records. On the other hand, it's also a lot easier to access the records, if you've got permission; wiretaps are something that have to be explicitly set up. (CALEA makes it easier to do the wiretap, but very few employees would have access to that kind of thing, as opposed to the FBI accessing it.)
The Havenco folks were well connected with the Cypherpunks group that hung out in Anguilla back during the 90s boom. It was outside the US, so legal to develop cryptography there when it wasn't quite legal here, and it was a tropical island with good beaches and a friendly English-speaking population. Some of the group are still there, and have been running the.ai country-code TLD from the island for some time (for a few years, the ccTLD's DNS server was located in a bedroom in Berkeley:-)
They never did get more than rudimentary services going from the island, and they had several sets of falling out between the participants, which doomed it. I knew several of the Americans involved, and it was probably a failure before Ryan left, but certainly after; it wasn't a kind of business that the Royal Family really knew how to run.
The point of the place was largely that you could host material that was normally illegal or (more to the point for businesses) would have been taxable if it had been run from the UK. So gambling websites were a major target market, and tax avoidance / evasion in general, and of course music/movie/software piracy. It could have been tolerated, like the pirate radio that Sealand had run in the (?)80s, and they were working on getting a second set network feed from the Netherlands to provide regulatory diversity in addition to physical diversity.
I'm surprised by how much better her face looks - the original picture (at least as rendered by the BBC) looked really grainy, while the "improved" picture doesn't. It's not just her face, but the whole picture. Do you think they ran some kind of smoothing on it, or is the real problem is something like the BBC expanding/shrinking the document?
"vigilante" and "market-based" are synonymous here - the vigilantes were able to take them down by telling their service providers what was going on, and everybody dropped them except for a brief blip on Sunday from another service provider who hadn't gotten the message at first.
"mailing lists and other legitimate..." don't seem to have applied here; if you can believe the articles in the press, this wasn't a network that marketed itself to legitimate users, though there may have been a few people who naively thought that having their hosting be "bullet-proof" was a good thing.
"laws against it" don't seem to be an issue.
"Armies of worm-ridden Windows boxes" were actually the target here - McColo appears to have been where the bots masters hung out. They'll move, of course, but it'll take them a little while.
"Extreme profitability of spam" - Alas, you've got me there - they'll be back as soon as they can, or somebody else will take their place. It's still a game of whack-a-mole, but we found a whole bunch of moles hanging out less than one hammer-distance apart, kind of like the lemmings that the Disney folks threw off cliffs.
But at least we're getting a brief break while they enjoy their 15 minutes of infamy - I've seen some network operators who reported 90% drops in their email load who'd initially wondered if they'd just broken something with the other work they were doing that day.
Yeah, but the importance of Tier 1 status is pretty much about ego. It's partly about money, of course, since you'd rather not have to pay somebody when you can connect for free, and partly about the risk that once Sprint depeers you, other carriers might also, causing you to pay more money, but it's mostly about ego.
Of course, there are some customers whose buying decisions are based on their perception of your size and stability, and being Only-Tier-1.5 might look less big, but getting your name in the paper every year or two because of depeering fights makes you look less stable, so you pays your money and takes your choice.
Back when I had a lawn of my own, I grew mint in the strip of garden next to my house. It's a very invasive plant, and the couple of feet of lawn next to the garden were about half mint. Mowing it was quite enjoyable.
(There was also a pot plant that showed up volunteer next to the garage, courtesy of the previous owner's kids' gardening. Unfortunately my father was the one who found it, and I was too straight-laced in those days, so it ended up in the compost pile rather than dried and smoked.)
I suppose "given name" is as useful a term as any. "Surname" is still a positional term rather than a functional one, so it means "last name" rather than "family name", and is therefore not helpful.
If you're selling a bottle of it at a store, then yeah, it has to be 51% agave. If Tony's pouring it out of a jug at his restaurant, it needs to be at least vaguely tequila flavored.
Last news I read on the subject was that there had been a shortage a couple of years ago, mainly due to rapidly increasing US popularity, but then agave farmers overplanted and now there's an oversupply (so you're seeing things like agave syrup at Whole Paycheck) and farmers are looking at tearing it out and going to other crops.
At least with tequila, there's some chance for the market to adapt, as opposed to single-malt scotch or something. The agave still takes some time to grow, but most distillers aren't aging their product more than 2 years, usually rather less, as opposed to scotch where the cheap stuff is 8 years old. If you want Macallan to start making more of their 25-year-old stuff, get a time machine and let them know.
Polgamy and Christian values - technical correctio
on
Ender in Exile
·
· Score: 1
A technical correction here - Polygamy had been practiced in Judaism, at least as late as King Solomon, but was AFAICT pretty much gone by the time of Jesus, though it was widely practiced by many of the other religions and cultures in the Roman Empire. Christians weren't supposed to marry anyone beyond their first spouse, but already-polygamous converts didn't have to get divorced. On the other hand, you couldn't be a bishop if you had more than one wife.
Celibate priesthood was a later invention, though St. Paul was single and recommended against getting married if you were going to be a missionary, since traveling around getting shipwrecked, imprisoned, run out of town, fed to lions, etc. is no way to treat your wife and kids.
I agreed with Lewis's religious views, at least when he was writing theology books, and even so I found the preachiness in Narnia annoying. The preachiness in the Out of the Silent Planet was a bit more central to it, and fit a bit better.
Slashdot Mirror
We've known since the beginning that the security of RSA depends on the key length that computers can factor using the latest algorithms. 10-bit keys were always too short; 512-bit keys were cracked in 1999, and Shamir ("S" in "RSA") published work in 2003 suggesting that 1024-bit keys might be endangerable soon - they're probably fine for one-shot use on any individual message less important than planning the overthrow of a large government, and they're certainly fine for bank transactions, because the cost of breaking them far exceeds the amount of money in your bank account. But for a single long-term hard-to-change widely-used target, like the DNS root or .com, RSA1024 is pretty dubious. It's probably fine for signing www.yourdomain.com unless your domain is a large bank, but the protocol needs to support keys that are long enough for everybody, which means it needs to be 2048 or longer.
Unfortunately, DNS has fairly tight constraints on how many bits you can cram into a transaction, and 2048 bits isn't very practical. ECC uses much shorter keys, and while 160 bits isn't quite long enough, 255 appears to be really good, unless some improvement in the theory changes that.
But yeah, elliptic curve theory is a lot newer than factoring theory, and the risk of a theoretical breakthrough is a lot higher, though Moore's Law isn't much of a threat for a while. On the other hand, DNScurve uses ECC for transactions, not for long-term signatures, so there isn't the same One Big Target effect, since every DNS server is using its own different key.
Most copper looks like one of two things - pipes of a few standard diameters, or wires of a few standard gauges. A pile of M pieces of N-foot lengths of 1-inch pipe looks the same whether you just bought it or stole it from somebody, and if you're dealing with obviously-used pipe, you can chop it up into different lengths than the original (assuming you didn't already do that as part of the process of ripping it out of the house...) No foundry required.
If copper wire dealers wanted to get fancy, they could put serial numbers on wire reels, to make it a little less untraceable when you're selling "some wire left over from a building job", but they're not going to serialize the wire. I suppose a contractor could randomly spraypaint the stuff when installing it, which'd at least make it look obviously used, but again, a foundry isn't needed.
And you can always let the stuff hang around in your garage or your cousin's junkyard for a few months if you need to anonymize it a bit more, though that's more of a trick for professional thieves than amateur meth-heads.
Hey, my phone's running low on power, let me find some heavy traffic and big trucks so it'll be loud enough for me to hear you!"
Next thing you know you'll have to shake your phone to get features to work (oh, wait...)
There are three basic numbers of gTLDs we can support - a few, a few hundred to few thousand, and near-infinite.
There are organizations that'll want to register under every new TLD, and other organizations that won't care, but if there are a hundred gTLDs, people will increasingly not care. (I'm surprised anybody who bought a .biz name when they were new would bother renewing it these days - too much spam and junk.) On the other hand, ICANN has the monopoly on the space, so they don't want to let the price drop unless they'll get really high volume - 20-50 gTLDs at $100K each make more money for less work than 1000 gTLDs at $1000, but maybe there's a market for 1000 of them at $10K.
The Marines are using the domain name marines.com in addition to marines.mil. Obviously this means they're in commercial business - attacking countries for hire, etc. Appalling, but at least under the Bush Administration they're willing to admit it. (Actually it's mostly a recruiting site, because they're trying to hire people who don't know to look under usmc.mil or marines.mil :-)
Go read the RFCs for DNS and look at the packet format picures- if you were writing DNS from scratch, that'd be an obvious thing to change (though I'd recommend 128 bits.) But the Transaction ID isn't one of the fields that you get to pick a size for, or one of the record types that you can replace with a newer record type such as IPv6's AAAA records instead of IPv4's A records or the various record types that DNSSEC uses. It's one of the early fields in the packet, always the same size, always 16 bits. Fixing that would require rolling out a whole new version of all the DNS tools in existence, and that's probably harder than getting IPv6 deployed.
What the fixes do is to also use the UDP port number that the query comes from for verification, so your DNS resolver won't accept a response for www.example.com on port 12345 unless it sent the request on that port (many DNS implementations used to send all the requests from UDP 53, and it made firewalling easy.) This was especially easy to implement, because DNS servers already send the response to the port where the request came from, so it only required changing the client end.
The fixes still aren't enough - an attacker now needs to send ~2^24 attack packets, since the transaction ID can still be birthday-attacked, but it's a lot safer the older versions where ~2^8 packets was enough. So we still need something extra, and DNSSEC solves a range of other problems.
Yes, there were some DNS systems that randomized port numbers already, so they're safe against birthday attacks on the 16-bit ID. DJB's obsessively careful, and at times like this it shows. But the ID's still only 16 bits long, and port numbers only get you another ~16 bits, so a ~2^24 packet attack can still succeed. That's not always going to work, but attackers don't have to win every time to be dangerous - they don't need to attack your account at your bank, as long as they can rip off somebody's account at some bank.
There are two basic approaches to fixing the problem - make the transaction ID enough longer that it can't be spoofed, or add a separate signature mechanism like DNSSEC. The first approach is unrealistic, because you'd need to deploy a new version of the DNS protocol, not just new implementations (even IPv6 keeps the same DNS version and transaction ID, and just adds more record types, which DNS is designed to support) - so good luck with that. The second approach has its difficulties as well, and there are other ways that digital signatures could be added, but DNSSEC is the closest to deployable that we've got.
Kaminsky wasn't an unknown - he'd spoken at a couple of Codecon conferences, doing increasingly heinous things to DNS. One year it was tunnelling SSH over DNS, which lets you break out of any firewall you're behind (and potentially lets malware do the same.) Another year it was the video-over-DNS hack referred to in the article. Codecon's not a big conference, but it's had a lot of high-quality presentations, and when I saw the announcement that Kaminsky had found a serious problem, it had to be more serious than merely breaking through firewalls...
DNS has two things that identify a UDP request - the transaction ID and the request's port number. 16 bits of ID seemed like plenty back in 1983, and many DNS versions didn't randomize the port number (since it's easier to just use 53 both ways through your firewall) before Kaminsky forced them to fix it. By requesting lots of bogus subdomains, you can birthday-attack the system, so you need ~256 guesses instead of 65536, and it's a lot easier to win that race against a real query.
But even the port-number fixes don't get you solid protection - they just raise the attack difficulty by a factor of a few thousand, so the attacker has to be a bit more determined. But an attacker doesn't need to be successful on every target or every DNS server to make money - there are lots of banks, and lots of users, and sending a few billion packets costs less than the amount he can steal if he's successful.
Changing the protocol would work just as well as deploying DNSSEC - a 128-bit ID would protect against birthday attacks - but that'd be much harder to get deployed. The port-number-randomization approach is at least a stopgap.
A few things have changed since my 2003 /. post which I've attached below, but the main difference is that Kaminsky's attack has made people realize that DNSSEC matters, and that it's time to get the ICANN and Department of Commerce to sign the root and have the registries sign .com and other major domains. (It's fun watching the Feds panic about it, because much of it's their fault.) And while widespread IPv6 deployment is closer, IPv6 DNS just uses the same packet format as IPv4 DNS with some new record types, so it has the same vulnerabilities.
=============== Political Problems with DNSSEC =====
Some of the problems with DNSSEC are technical - most of them have to do with making things fit inside 512-byte packets and not breaking too many server implementations. But the big problems have been political, including politics implied by the protocol structure and politics that's separate from it.
Yes, Engineers understand math, at least to some extent. (I was surprised in grad school about how much more rigor was possible compared to doing the same material as an undergrad or high school student :-) And some kinds of engineers use appropriate math for what they're doing. Dijkstra's arguing here that software engineers generally don't. Sure, we'll occasionally apply order-of-magnitude math to our algorithms, deciding whether an N**2 or NlogN is a better choice for the size of data we're dealing with, but computer scientists have been bitching about the lack of use of program-correctness proofs for at least a decade before Dijkstra's talk, and even though our computers are 4 orders of magnitude faster and 6 orders more price-performing than when he wrote the talk, we still consider that stuff too inefficient for practical use and write lots of buggy code.
A simpler example than proof-of-correctness is input validation. A program is designed to take a given set of input and produce corresponding outputs, so one way to improve program correctness is to start by specifying the input set and validating whether the input the program receives is in that set and reject it if it's not. (Replaces "Garbage In Garbage Out" with "Garbage In Error Message Out".) My CS100 professor emphasized that ~30 years ago and made us run all of our homework programs on maliciously designed input, but how many of the security bugs you see today are still buffer overruns or stack smashing or other because people aren't bothering to define and enforce the valid input sets. It's improved a bit with object-oriented programming because objects are a bit more restrictive in what kinds of input they'll accept, and many of the popular objects validate their input and are almost as easy to use as similar objects that don't, as opposed to rolling your own lazily or using C's getwhatevers().
I partly blame Knuth for this :-) His books were the canonical algorithm books for a generation, and did the math really really well, but did programming examples in a baroquely ugly assembler language or spaghetti-pseudocode when better languages were available (e.g. Algol or cleaner assemblers), and that made it hard to learn how to apply his mathematical techniques to real programming.
Unfortunately, Ballmer's current cunning plan, Vista, hasn't worked out :-) The next cunning plan, V7, probably won't do worse, and maybe will do better, but by around XP time the CPU people had pretty much outrun MS, and the RAM people have also gotten ahead of it even with DDR or certainly by DDR2. One thing I'm missing by not doing Vista is the cache-on-flash feature, which is too bad; it'd let my disks spin down most of the time.
The other traditional driver for the CPU makers has been gamers, who can use all the power they're given, but the last few rounds that's mostly been in the graphics board camp, not the CPU camp; we'll see if the CPU side starts integrating more graphics functions or if the game companies increasingly leave PCs for consoles. (I'm not the target audience for that; I'll probably continue using mobo-builtin graphic unless my next LCD flatscreen needs a different interface, in which case I'll buy a =$49 board, and Nethack never did need all that DirectX anyway :-)
There's only so much spectrum out there, especially if they use longer-wavelength systems which get better distance and penetration and therefore have more users per chunk of bandwidth. So it's going to have a lot less average bandwidth per user than wired systems, regardless of what the airspeed of any given connection might be. That's going to annoy the kinds of people who gripe about Americans having a lot less bandwidth than [cliche]old people in Korea[/cliche], and it's not going to handle BitTorrent or streaming video downloads reliably, but it'll probably beat modems and text messaging.
Yes, there's a Social Security Trust Fund that's invested in T-bills. That just means that they've taken any surplus they had in the past and lent it to the Government, which spent it, and which promises to tax people in the future to pay it back. So when all of us Boomers start retiring and not dying off quickly enough, not only will the Social Security Tax on working people not be enough to cover the costs, but the Feds will have to start running a budget surplus to pay off the debt, instead of continually borrowing more like they did while we were working. So it's going to suck to be young and working, or old and collecting taxable interest on our savings.
Before Bush took power, we had a $5T national debt, because previous administrations didn't have the financial discipline to not run deficits even during boom years. Bush's Fiscally Responsible Small Government Republicans doubled that before the Crisis, and it looks like they're spending another $5T-10T on bailouts (though ostensibly they'll get some of that back.) The current total debt is about 1 US GDP, or about $50K/American.
And to the extent that us older people saved money in forms other than houses (oops), we'll be getting lower interest rates on what we saved than what I'd been planning on, because more of us will be competing to invest it in whatever businesses the younger people who are working are running. So it's going to suck to be old and not working. And because it's also going to suck to be young and working, those people aren't going to be buying $5 coffees that much, and Walmart only needs so many greeters, so obvious old-people jobs are going to be scarce.
From a legal perspective, wiretapping to listen to the audio of a call is more more serious than looking at the records. On the other hand, it's also a lot easier to access the records, if you've got permission; wiretaps are something that have to be explicitly set up. (CALEA makes it easier to do the wiretap, but very few employees would have access to that kind of thing, as opposed to the FBI accessing it.)
The Havenco folks were well connected with the Cypherpunks group that hung out in Anguilla back during the 90s boom. It was outside the US, so legal to develop cryptography there when it wasn't quite legal here, and it was a tropical island with good beaches and a friendly English-speaking population. Some of the group are still there, and have been running the .ai country-code TLD from the island for some time (for a few years, the ccTLD's DNS server was located in a bedroom in Berkeley :-)
They never did get more than rudimentary services going from the island, and they had several sets of falling out between the participants, which doomed it. I knew several of the Americans involved, and it was probably a failure before Ryan left, but certainly after; it wasn't a kind of business that the Royal Family really knew how to run.
The point of the place was largely that you could host material that was normally illegal or (more to the point for businesses) would have been taxable if it had been run from the UK. So gambling websites were a major target market, and tax avoidance / evasion in general, and of course music/movie/software piracy. It could have been tolerated, like the pirate radio that Sealand had run in the (?)80s, and they were working on getting a second set network feed from the Netherlands to provide regulatory diversity in addition to physical diversity.
I'm surprised by how much better her face looks - the original picture (at least as rendered by the BBC) looked really grainy, while the "improved" picture doesn't. It's not just her face, but the whole picture. Do you think they ran some kind of smoothing on it, or is the real problem is something like the BBC expanding/shrinking the document?
But at least we're getting a brief break while they enjoy their 15 minutes of infamy - I've seen some network operators who reported 90% drops in their email load who'd initially wondered if they'd just broken something with the other work they were doing that day.
Yeah, but the importance of Tier 1 status is pretty much about ego. It's partly about money, of course, since you'd rather not have to pay somebody when you can connect for free, and partly about the risk that once Sprint depeers you, other carriers might also, causing you to pay more money, but it's mostly about ego.
Of course, there are some customers whose buying decisions are based on their perception of your size and stability, and being Only-Tier-1.5 might look less big, but getting your name in the paper every year or two because of depeering fights makes you look less stable, so you pays your money and takes your choice.
Back when I had a lawn of my own, I grew mint in the strip of garden next to my house. It's a very invasive plant, and the couple of feet of lawn next to the garden were about half mint. Mowing it was quite enjoyable.
(There was also a pot plant that showed up volunteer next to the garage, courtesy of the previous owner's kids' gardening. Unfortunately my father was the one who found it, and I was too straight-laced in those days, so it ended up in the compost pile rather than dried and smoked.)
I suppose "given name" is as useful a term as any. "Surname" is still a positional term rather than a functional one, so it means "last name" rather than "family name", and is therefore not helpful.
If you're selling a bottle of it at a store, then yeah, it has to be 51% agave. If Tony's pouring it out of a jug at his restaurant, it needs to be at least vaguely tequila flavored.
Last news I read on the subject was that there had been a shortage a couple of years ago, mainly due to rapidly increasing US popularity, but then agave farmers overplanted and now there's an oversupply (so you're seeing things like agave syrup at Whole Paycheck) and farmers are looking at tearing it out and going to other crops.
At least with tequila, there's some chance for the market to adapt, as opposed to single-malt scotch or something. The agave still takes some time to grow, but most distillers aren't aging their product more than 2 years, usually rather less, as opposed to scotch where the cheap stuff is 8 years old. If you want Macallan to start making more of their 25-year-old stuff, get a time machine and let them know.
A technical correction here - Polygamy had been practiced in Judaism, at least as late as King Solomon, but was AFAICT pretty much gone by the time of Jesus, though it was widely practiced by many of the other religions and cultures in the Roman Empire. Christians weren't supposed to marry anyone beyond their first spouse, but already-polygamous converts didn't have to get divorced. On the other hand, you couldn't be a bishop if you had more than one wife.
Celibate priesthood was a later invention, though St. Paul was single and recommended against getting married if you were going to be a missionary, since traveling around getting shipwrecked, imprisoned, run out of town, fed to lions, etc. is no way to treat your wife and kids.
I agreed with Lewis's religious views, at least when he was writing theology books, and even so I found the preachiness in Narnia annoying. The preachiness in the Out of the Silent Planet was a bit more central to it, and fit a bit better.