Yes, Spam does increase network costs, but not much. The real cost is the readers' attention span, which is much more expensive. I get lots of spam, but probably less than a megabyte per day, and I consume a lot more web surfing. Storing the spam doesn't cost anywhere near as storing my real email (at least my work email, which often has MSWord and MSPowerpoint attachments), because spam gets deleted. It's the human effort of filtering and updating filters and trashing obviously spammy subjects that slipped through that's the cost. Machines do the rest... they're cheap.
It's news - getting this stuff to work has taken them forever, and while some of this has been implementation slowness or tedious debugging that Hugh can rant about, doing Opportunistic Encryption properly is hard, and is harder than it looks, and they kept getting little surprises about what "properly" really did or didn't mean in practice as things that looked like good choices made other things broken. So getting from their aymptotic 1.8, 1.9, 1.9.9, 1.9.9.9, 1.9.9.9.9 to genuine 2.0 is news, because this does have useful and interesting new capabilities.
I'd hesitate to call something "automagically" when it required convincing your ISP that you want your reverse DNS entry (which they administer) updated with your IPSEC keys, which may also require installing a different DNS server than the one they were using (or at least a much newer version), and if they're a big ISP, it probably also requires tweaking the friendly automation scripts they were using to update the reverse DNS entries, unless they were the type of clueless ISP that didn't even bother with that,or if they were clueful but lazy, your DNS entry probably said "port32.box15.paloalto.ca.example.net", especially if you've got a dynamic IP address (or dialup) instead of static.
On the other hand, they've gotten it to the point that you don't need reverse DNSsec, just forward DNSsec, if you're only going to initiate connections and not respond to them, which is pretty common for dynamic-addressed systems. (Yes, you can use one of those dynamic-dns-updater services to work around this so you can run webservers and such, and in fact the freeswan docs point to one that's clueful about DNSsec, or plans to be really soon, but of course those can only do forward DNS and not reverse.)
A big part of the problem is that doing IPSEC properly means there's No User Interface except at machine setup time. A router or security gateway doesn't have end-users on it, and if you want applications to work in the general case, you can't depend on there being a user running a "Fetch keys for chernenko@kremvax.su" command to set up a connection before sending packets - the operating system or router just gets handed a packet for IP address 1.2.3.4 and has to decide whether it knows how to build an encrypted tunnel there or whether it should just route it, and it needs to decide and then do it before whatever underlying application times out or gets grouchy and retransmits. Prefetching keys could make this much much cleaner, but at best you can only make that work 90% of the time for end systems, and that means that 10% of the time you get mysterious failures, most often on services that don't have user interfaces, like server-to-server mail and DNS traffic that you don't want to screw up.
I also blame a lot of the difficulty of getting OE to work on the NSA's help with IKE/ISAKMP/OAKLEY - it's one of those Not-Malice-Just-Stupidity things. Opportunistic encryption wasn't the model of the world that the NSA or many of the other early standards developers were coming from, and many of them were more interested in kitchen-sink creeping featurism for the parts of the user space they did care about, and there was a lot of Not-Invented-Hereness around Photuris-vs-SKIP-vs-Oakley. The standard is too complex, has too many messages, and the pieces need to be done in orders that can make it difficult to implement well. Some of this wasn't realized for a while because people were focusing on the IPSEC problem - how to make things work on late-80s architectures and horsepower limits, and whether to use single-DES or triple-DES, and dealing with the NSA's/FBI's anti-crypto-export rules (ok, that part was malice, though collateral damage to IPSEC, but in fact you didn't _want_ to have to do 3DES in real-time on an 8086 or 68010 or 8051...) And businesses were focused on the VPN problem as well, because it's the part with the obvious customer base.
I'm really surprised to hear UUNET complaining about IPSEC. They shouldn't care.
However, there are some cable modem companies that really object to anything VPN-like. It's nothing technical, just pure greed. They assume that if you're using IPSEC, it's a VPN for work, and they have a higher price for "business ISP service" than for "residential". There are even a few DSL companies this rude and clueless. Most Cable modem companies and some DSL companies also object to running anything server-like on their networks, because they're worried about overloading their asymmetrically small upstreams, and because they've got a leftover habit of paranoia about bad performance due to early equipment problems, all those PacBell "WebHog" TV commercials, worries about bad PR from neighborhood porn web servers hogging the cable, etc.
While most cable modem companies are still desparately clue-deficient, they've at least mostly figured out that one reason people are buying broadband in the first place is to be able to work from home, and that means that customers _are_ going to use IPSEC and not just fetch HTTP and POP3, and now that telco DSL service is widespread, they're a little more responsive to competitive pressure.
Some telco DSL providers are apparently clueless about this also, but relatively few.
VPNs are an easier way to use IPSEC than Opportunistic Encryption is - they're designed for only talking to machines you know and trust and have administrative relationships with, so it's a much simpler problem. As kmcmartin points out, FreeS/WAN has had this since early on (at least in combination with the standard firewalling capabilities.) In addition to letting ipsec packets through, you actually also need to allow UDP 500, which is the connection setup protocols, and you usually want DNS as well, depending on how you plan to identify machines that you're willing to talk to.
Cisco routers have IPSEC capabilities, if you want to pay extra for the IOS versions that support it. Most Cisco routers have really wimpy CPUs, so if you're trying to handle any real volume, you'll want a crypto accelerator board also. Basically, you end up paying over $5000 for a router that would otherwise be under $2000 (or ~$500 on e-bay:-) (YMMV on Juniper or Lucent or Nortel or other router brands, but it tends to be true there too.) By contrast, a Pentium-200 can pretty much handle IPSEC for a 10mbps Ethernet load, and you might as well just build the crypto into your web server or mail server since you're more likely to use a 2GHz machine instead. If you want to build an appliance, those 206-MHz StrongArm boards are pretty popular.
The debate about whether to do crypto at Layer 1, 2, 3, 4, or 7 has been going on for over a decade and a half. (Some people argue that crypto in the SSL/SSH sense is really layer 5 or 6, one of those OSI Session or Presentation Layer things that the TCP world doesn't worry too much about, but alternatively you can call it Layer 4:-) Physical and Link-Layer crypto are fine for private networks - WEP is basically a Layer 2 crypto system which would be a good thing if it weren't badly thought out and badly implemented, and the NSA has been using Layer 2ish crypto on X.25 networks since the 80s, back when X.25 was the way you did international data networks. IPSEC has the advantage that it protects _all_ the communications between your machine and another machine, which can be really effective if that matches your communication patterns, and it means that the applications inside don't need to be modified to use crypto as long as they run over vanilla IP. Layer 4 cryptosystems like SSL and SSH are much more trouble - applications need to know about them, and they don't protect the machine against protocols that don't use them, but the operating system doesn't need to know, and intermediate routers and such don't need to know about it, so it can be more convenient to implement for applications that can use it. Layer 7 - things like PGP-or-S/MIME-encrypted email or encrypted file systems - is obviously much more customized, protects even fewer things, but sometimes it's the right way to go also.
John Gilmore and his friends, including the EFF, Cypherpunks, and academic crypto community, have been annoyances to the NSA and their ilk for years. He's done things to them like winning lawsuits in Federal court to get fundamental books on crypto declassified (after doing the search to find one public library that had copies of them), funding the EFF DES cracker machine design to drive the nail into the "56-bit DES is good enough for you" rulemakers (after the "40-bit RC4 is good enough for you" had been cracked by various grad students and implemented on T-Shirts) (And by the way, the NSA never returned the T-shirts that Raph Levien submitted for munitions-export approval...). The more important work was probably the social organization that helped make people aware that this is a civil liberties issue as well as a geek-technology thing.
A lot of credit also has to go to Netscape, who put encryption technology on everybody's desktop by including it in their browsers, which of course forced Microsoft to include it in IE as well. It's a different technical approach to attaching the crypto to the network, but you can use web browsers to downloaded encrypted files, read your webmail, etc., which is a large part of the problem space. Some of the core Netscape crypto developers were three brothers who also hung around Cypherpunks... The fact than a one-line ascii patch could "fix" the 40-bit crypto in Netscape and make it 128-bit was only partly technical convenience. And the "Develop and ship the code so people can use it" approach to protecting civil liberties is a lot more direct than ask-permission-first lawsuits, though some people went to extreme risk trying to keep their asses out of jail after doing so, like Phil Zimmermann. The FreeS/WAN people have also been taking this approach for a long time - it's developed entirely outside the US to avoid being subject to US crypto export requirements (John's a funder, and a user, not a developer for this stuff.)
Technology like this _has_ been rolled into popular software - the Internet stimulated awareness of the business need for crypto at around the same time that computers got fast enough to make it relatively practical. Virtual Private Networks are a different part of the IPSEC space than Opportunistic Encryption, since they're designed for letting approved people have a private conversation rather than letting just anybody access your machine, but they've been a standard business capability for a few years now - otherwise telecommuters would have to dial into dedicated modem pools, and if you remember running those, they were expensive and annoying to maintain. The IPSEC crew were an important part of the industry standards work, going to the various bake-offs to make sure things really interoperated, and having a free implementation that was vendor-neutral was a big help in getting everybody working together during the early still-flaky days. Middle-aged Microsoft operating systems had PPTP VPNs on them. They were terribly broken, and I think the WinXP stuff has real IPSEC built in, though that may only be XP Pro. And gradually there'll be better-working stuff there.
There are a lot of packages using SSL and SSH to do crypto
SSH has pretty much replaced telnet as a way to administer machines remotely, except when you can use SSL-encrypted web forms.
Client-side SSL certificates haven't really taken off yet, but server-side certs are enough for most of the problem. I think some of the SSL-based clientless VPNs like Neoteris use Client-side.
The last several SMTP versions have supported SSL/TLS encryption, so you finally can send your email encrypted among systems that support it, with the servers supporting the encryption rather than having to encrypt every message.
Microsoft Outlook and Eudora and some other email packages support crypto as a standard feature, using S/MIME. They also support plug-ins, which means that PGP integrates into them pretty cleanly, so you can send encrypted email to people whose public keys you have, and in some cases can fetch the keys automatically from LDAP servers if your corporate email does that.
I don't know what you mean by "streaming", if you're talking about DES at least, but triple-DES is just fine. The effective key length is only 112 bits (2*56) rather than 168 bits (3*56), because of the meet-in-the-middle attack which uses 2**56 objects of memory to reduce the computation time, but that's still pretty good given forseeable technology. (Among other things, hypothetical quantum computers are hypothetically very annoying to factoring-based public-key crypto, but at most provide an N**2 attack on non-factoring-based crypto, so maybe you'd need to use 5DES instead of 3DES.)
If your reference to streaming is to things like RC4, as opposed to OFB or similar DES modes, RC4-40 is of course toast, as demonstrated so thoroughly a couple of years ago that NSA gave up on making rules about it. The distributed.net folks apparently don't know when to quit:-), so they not only cracked RC5-56 and just recently RC5-64, but are going for RC5-72. RC4-128 is just fine, except if you use it for things it wasn't designed for (3 or 4 of the 7 main things wrong with Microsoft's PPTP were boneheaded-dumb misuse of RC4's requirements, and the WEP 802.11 folks found more creative ways to use RC4 for things it wasn't meant to do.) But as long as you use it the way it was designed to be used, it's strong enough, and it's just about the minimum-CPU crypto algorithm out there for general-purpose computers.
I'm not bothered that the most common SSL implementations do RC4-128 instead of 3DES - they usually have much more serious implementation problems (:-), such as not firewalling the hardware adequately, and they should also generally be using Perfect Forward Secrecy modes and often aren't.
The whole point of mathematical cryptography is understanding the work level required to crack it so you can decide whether an algorithm is good enough for what you need. One of the nice things about public-key crypto is that you can make the key longer at roughly N**2 cost, which increases the cracking effort by roughly 2**(N/logN) *, so if you are willing to quadruple your computation time, you increase the cracking effort by a factor of ~2**100, pushing it out of the range of things that can be cracked with current technology during the lifetime of the known universe. The longest RSA keys that have been cracked are on the order of 600 bits. There's some evidence that if anyone built Shamir's TWIRL hardware, for a cost of ~$50m, it might be possible to crack 1024-bit keys in under a year, so you might want to use 2048-bit RSA for anything the government might be interested in this decade, depending on what you believe about Moore's Law's longevity. But basically, it's easier and cheaper for them to sneak in and put a bug in your keyboard than to crack your keys mathematically.
The author's posting sounds like those people who troll about "NSA put a backdoor in PGP" and rot like that. Some of them are motivated by the fun of trolling, while some sound like they're spook sympathizers deliberately trying to undermine the public's use of crypto.
In sheenmaster@frob.us 's case, he's got a product on his website about his product FlameCrypt, which given his Slashdot posting I wouldn't touch with a 10-foot pole even if it did have documentation and the algorithms posted where you can get at it without registering on his site and/or downloading the program. Crypto people are concerned about privacy and about good documentation.... What I could find about it on Google\(tm was a reference to earlier versions that let you put in your own algorithms and "an algorithm generator program to automatically create new algorithms." Pure snake oil, which is consistent with his flame. Too bad - his web site had an entertaining counterflame about all the spelingg missteaks being intenshunnul.
*Minor exception - Elliptic Curve is 2**N, so it can get away with shorter keys than RSA or Diffie Hellman, but it's a newer theory and not everybody's convinced that a theoretical crack won't show up. It tends to have annoying patents on some of the versions as well, but it's convenient to be able to use 165-bit keys instead of 1024- or 2048-bit keys when you're trying to save space in packets or autogenerate the keys from passphrases. Also, the work factor I gave for RSA cracking is very approximate, and depends on what the best factoring algorithms are this year. But the basic principle has been constant for a long time, which is that a small linear or quadratic increase in encryption workload causes a basically exponential increase in cracker workload, and we've been on the pro-privacy side of that curve since before PGP first came out. Moore's law has meant that since PGP was good enough to use 512-bit keys on an 8086 in 1991, and 1024-bit keys on a state-of-the-art 386, back then, 2048-bit keys have been usable since about 1994 on a Walmart-quality PC, and your cellphone could have been running 1024 bit keys by about 1997 if the NSA and their equivalent thugs in Europe weren't pretending that they were forcing cellphone companies to use crippled crypto to keep the Commies from using it.
It's very easy to get something like opportunistic encryption if you're not worried about "Man In The Middle" attacks - you do pre-shared secrets, with the standard passphrase "open secret", and that lets everybody set up encrypted connections. They could have had this out a couple of years ago (pre-shared secrets were the standard way to get ipsec boxes from different vendors to talk to each other.) But it falls easily to man-in-the-middle attacks, (to the extent that mitm attacks are easy, which they're not if you're careful) so they considered that to be broken.
In general, the problem of "how do you have a secure conversation with a stranger?" in unsolvable. If you're communicating with somebody you know, you can set up pre-shared keys or X.509 keys or some equivalent and use them. We've had VPNs for a couple of years, and FreeS/WAN has done them, which address the problem of only talking to your friends. This stuff is relatively cool, except that most people don't have good control over their reverse DNS, even if they do have static IP.
Obviously you deal with such as shocking color mismatch by putting them in an opaque box. I realize that boxes with NO WINDOWS on them are a shocking design decision these days, but you need to consider it.
The other alternative is to get different colors of interior case lighting so you can't tell that the flashing purple light is over the greenish board and the flashing near-indigo lights are over the teal-colored boards...
There are three kinds of places that could send you an ad like that
The admaker company themselves --They get their site blacklisted heavily before and after some h4x0r k1dd13 scribbles it
The site you're visiting --They get LARTed pretty fast also, and hopefully learn their lesson before Darwin gets them.
Third parties, like banner services only worse. They need to find all kinds of bad things happening to themselves....
In general, people who design "user experiences" need to have some understanding of the user environment before selling their services. Otherwise they'll end up like that Pointcast service that didn't understand caching, which everybody really liked for a week or two before it was obvious that it trashed everybody's network performance, at which point sysadmins all blocked it. (Remember how "push media" was going to be the next cool wave of the future thing:-)
I've got DSL at home, so a 300K download is pretty fast, but it's still worth emailing the designers a copy of Mozilla so they can try out their product on a REAL browser... ("Here's my browser - try out your software on THIS!") and even making a couple of voice telephone calls to the company pushing them and its whois contacts. Companies that have 800-numbers sometimes really don't like getting their phones slashdotted with complaints, and if it happens to the customer as well as the supplier of this kind of adware, sometimes they get the hint.
Look, there aren't many reasons for using Windows out there. MSOffice can be somewhat emulated with OpenOffice and such, most tools for network-related activities are much easier to build and support on Unix, email clients and web servers are much better on Unix, most tools for computation are easier to build and support on Unix, GUIs can be done anywhere depending on what toolkits you like, and video production is still usually a Macintosh thing.
Games are the reason for buying that new 7GHz machine with the gigabyte video card in it, and games are the hard-to-port reason for buying Windows, just as they're the reason for buying Gamez hardware platforms, because they're unique products (unlike Office, where a similar product running on a different OS is just fine.) So if good portability tools let game writers hang onto Windows a bit longer, fine, that still means that more of the important industry-driving products (:-) run on Linux as well.
Hmmmmm... sounds like a Soylent Green commercial "debian is PEOPLE":-) Anyway, back to the topic...
Debian is a group of people who have SOFTWARE distributions, including a bunch of software distribution tools like apt-get. Usually people use their Linux distros, and use apt-get to get Linux updates, but they've also been working on other Unix-like distros, such as their GNU/HURD package. Unix in general has been intended to be a portable operating system, with applications that are portable (and often get ported to other operating systems, partly because C is a relatively portable language and partly because the models for interacting with the OS can be packaged in a variety of libraries to match the underlying platform.) So this one's using a *BSD kernel, with most of the same GNU and X and other non-GNU tools that they also run on Linux and HURD.
Tracing back from the mail server to the spammer is more the goal of Larry Lessig's proposal which Zoe Lofgren is putting into a Federal anti-spammer bounty bill. This initiative seems to be more targeted at doing something to the spammers once you've caught them, though the details aren't particularly clear.
Back when the MAPS Open Relay Blackhole List stuff was new, they blacklisted Netcom, which was my ISP (I forget it they were still Netcom or if they'd been eaten by Mindspring or Earthlink by then.) I found out about it when some of my email started bouncing, but at least the MAPS blocking produced human-readable error messages, which was one of the main objectives of the blacklist.
It worked - there was lots of yelling and screaming, but in a month or so Netcom had closed their open email relays and gotten off the blacklist, and it got everybody's attention. In the meantime, I did what I had to do to get my email out, which was to use a different open mail relay at Netcom that the MAPS RBL hadn't noticed:-)
Their customers _are_ deciding what is or is not acceptable; if you don't like it, get your email somewhere else. AOL is a bit special compared to most commodity ISPs, but it's still just one of many vendors. It's certainly easier to make an informed decision if the ISP publishes the techniques they're using to block spam, but if one of them doesn't, that may be part of your criteria for not choosing them. However, having said that,....
There are two fundamentally different things that ISPs can do with suspected spam
Whole-ISP solutions that refuse to let it in the door at all (e.g. blocking all mail from open relays and suspected spamhausen, or using adaptive DNS responses so known relays think you live at 127.0.0.2 and don't even bother your sendmail.)
Per-customer solutions such as tagging or discarding suspected spam once it's in the door. This gives the customer a lot more choices, but it takes a lot more resources from the ISP, including bandwidth and CPU. The first approach lets them get rid of most of the high-volume dreck cheaply.
I'm not bothered by either of these approaches; as I said, you can pick whatever kind of ISP you like. What is more of a problem is ISPs that block incoming mail without proper error messages. If you're sending legitimate email and it gets spam-filtered and the user never sees it, that's annoying, but at minimum, anything that gets rejected by the ISP's SMTP server should get an RFC-compliant reject response so you know to try contacting the recipient again using your hotmail account or whatever.
Most of the things that local laws can do to stop spammers don't work because the spammers can move their operations somewhere else; the Internet is everywhere but local jurisdiction isn't supposed to be (though the US government doesn't mind sending terrorists to shoot down suspected drug dealers anywhere they want, not that I think we'll see the War on Spam getting militarized any time soon.) And most things the Feds could make laws about are actively harmful, e.g. banning anonymous email as opposed to only banning forged email.
But there are a couple of areas where US Federal laws could do as much good as harm, if they're written carefully enough to be effective as well as doing minimal collateral damage.
One is going after big US-based spammers who collect their money back in the US even if they abuse Korean relays or whatever to transmit spam.
Another is more effective remedies against people who forge yahoo/aol/hotmail return addresses.
Another approach is exceptions to existing anti-cracking and (more dangerously) anti-email-wiretapping laws. Some of the things you can do to stop spammers might be illegal, such as DDOSing machines that send mail to your honeypot accounts or using BGP to null-route their traffic. Some things might be "illegal restraint of trade" or other anti-trust issue if AOL, Yahoo, and MS gang up to block somebody, and while a random small spammer can't afford to sue them for it, a big spammer might risk it. Some of the things they might do to block spam include much more active processing of email than the ECPA really allows. If the Feds legalize some of the self-defense measures that are currently questionable, they may be able to hit back at some of the big spammers.
:-) No, the modem's not built into me, just into my computer. It took a long time before they actually reached me on the modem line, because normally if I was home, I'd have the (laptop) computer plugged into it, and if I wasn't home, I wouldn't know they'd called, but they eventually happened to call at a time that I didn't have the computer plugged in.
We've got the Sharper Image similar product at home. There are two problems with it - static and ozone. After using it for a while, the room starts to smell like ozone, somewhat similar to a chlorine bleach smell, which is why we stopped using it. Static isn't a problem for home use, but I'd worry about it in a computer environment.
It seems to do a decent job of picking up dust, though some of the dust will get through and stick to the wall next to it. Cleaning isn't hard if you've got a bathtub nearby; you just pop the static element out and run hot water on it. A janitor's closet sink should work fine in an office.
Tobacco dealers don't go shooting each other on street corners. Tobacco is more addictive than heroin, and costs about as much per user per day to make (all the rest is the cost of the black market.)
Liquor dealers don't go shooting each other on the street corners, though people do rob liquor stores and drunks do get into fights. A day's worth of medical-priced opiates is cheaper than a half-bottle of bad gin.
Zucchini dealers don't go shooting each other, though there are the occasional Midwestern terrorist events (leaving bags of zucchini on other people's doorsteps during the growing season); marijuana's about as easy to grow as zucchini if you're not trying to hide it from the cops.
If we legalize drugs, street gangs may not stop carrying, but they'll mostly stop dealing, because you'll be able to get better-quality pharmaceutical drugs at the drug store and marijuana at the tobacco or liquor store, and at that point drug dealing turns into honest work, not significantly more profitable than selling flowers on the street corners except for a bit of low-markup business selling to minors along with selling them cigarettes. Might as well go back to stealing hubcaps.
The standard thing to say to them in the US is "Put me on your don't call list". Almost all of them will. The last telemarketers I talked to for longer than that were
One that was unclear enough it took a couple of minutes to figure out quite what he was calling about to figure out that he was a telemarketer.
MCI, because I wanted to hassle one of their supervisors, because I had already asked to be on their don't call list (their system isn't bright enough not to apply the list to multiple phone numbers at the same household, and they were calling my modem. And I work for a telco, and not only did their best rate not beat our employee discount, their employee discount wasn't that hot either. But that was some years ago, and neither is ours now:-)
The California Narcotics Officers Association, or actually a telemarketer selling for them. They were the sleaziest, most evil cause that's ever called me on the phone. Not only do they run a "charity" that gives money to cops for violating people's individual human rights, they lobby for more drug laws and against medical marijuana, because their business would be hurt if people didn't consider their political correctness to be more important than pain suffered by cancer patients. I wasn't able to talk the telemarketer into stopping promoting them, but I did talk to several people there about them.
Yes, it did say 802.11. There are times that's what you want, but since this seems to be a relatively expensive small machine rather than a cheap small machine, some of the market for it will be specialized applications like system administrators who need to be able to plug it in to various networks to measure things. You can do USB internet if you want, and USB2.0 is even fast enough to support a fast ethernet (as opposed to 12 Mbps max), but it's somewhat annoying.
Great. Not only will you have the RIAA trying to bust you with a DMCA lawsuit because it's an MP3 player, they'll hire the BATF to do the bust instead of some wimpy process server! Yes, Mr. District Attorney, it violates the California ban on Scary-Looking-Weapons and it's Infringing Copyright, so we want you to go for the extra-5-years penalty for Using a Gun To Commit a Crime"
Slashdot Mirror
OpenBSD recently announced something similar. Are they in fact actually similar? Or are they just different approaches to the same problem?
I'd hesitate to call something "automagically" when it required convincing your ISP that you want your reverse DNS entry (which they administer) updated with your IPSEC keys, which may also require installing a different DNS server than the one they were using (or at least a much newer version), and if they're a big ISP, it probably also requires tweaking the friendly automation scripts they were using to update the reverse DNS entries, unless they were the type of clueless ISP that didn't even bother with that,or if they were clueful but lazy, your DNS entry probably said "port32.box15.paloalto.ca.example.net", especially if you've got a dynamic IP address (or dialup) instead of static.
On the other hand, they've gotten it to the point that you don't need reverse DNSsec, just forward DNSsec, if you're only going to initiate connections and not respond to them, which is pretty common for dynamic-addressed systems. (Yes, you can use one of those dynamic-dns-updater services to work around this so you can run webservers and such, and in fact the freeswan docs point to one that's clueful about DNSsec, or plans to be really soon, but of course those can only do forward DNS and not reverse.)
A big part of the problem is that doing IPSEC properly means there's No User Interface except at machine setup time. A router or security gateway doesn't have end-users on it, and if you want applications to work in the general case, you can't depend on there being a user running a "Fetch keys for chernenko@kremvax.su" command to set up a connection before sending packets - the operating system or router just gets handed a packet for IP address 1.2.3.4 and has to decide whether it knows how to build an encrypted tunnel there or whether it should just route it, and it needs to decide and then do it before whatever underlying application times out or gets grouchy and retransmits. Prefetching keys could make this much much cleaner, but at best you can only make that work 90% of the time for end systems, and that means that 10% of the time you get mysterious failures, most often on services that don't have user interfaces, like server-to-server mail and DNS traffic that you don't want to screw up.
I also blame a lot of the difficulty of getting OE to work on the NSA's help with IKE/ISAKMP/OAKLEY - it's one of those Not-Malice-Just-Stupidity things. Opportunistic encryption wasn't the model of the world that the NSA or many of the other early standards developers were coming from, and many of them were more interested in kitchen-sink creeping featurism for the parts of the user space they did care about, and there was a lot of Not-Invented-Hereness around Photuris-vs-SKIP-vs-Oakley. The standard is too complex, has too many messages, and the pieces need to be done in orders that can make it difficult to implement well. Some of this wasn't realized for a while because people were focusing on the IPSEC problem - how to make things work on late-80s architectures and horsepower limits, and whether to use single-DES or triple-DES, and dealing with the NSA's/FBI's anti-crypto-export rules (ok, that part was malice, though collateral damage to IPSEC, but in fact you didn't _want_ to have to do 3DES in real-time on an 8086 or 68010 or 8051...) And businesses were focused on the VPN problem as well, because it's the part with the obvious customer base.
However, there are some cable modem companies that really object to anything VPN-like. It's nothing technical, just pure greed. They assume that if you're using IPSEC, it's a VPN for work, and they have a higher price for "business ISP service" than for "residential". There are even a few DSL companies this rude and clueless. Most Cable modem companies and some DSL companies also object to running anything server-like on their networks, because they're worried about overloading their asymmetrically small upstreams, and because they've got a leftover habit of paranoia about bad performance due to early equipment problems, all those PacBell "WebHog" TV commercials, worries about bad PR from neighborhood porn web servers hogging the cable, etc.
While most cable modem companies are still desparately clue-deficient, they've at least mostly figured out that one reason people are buying broadband in the first place is to be able to work from home, and that means that customers _are_ going to use IPSEC and not just fetch HTTP and POP3, and now that telco DSL service is widespread, they're a little more responsive to competitive pressure.
Some telco DSL providers are apparently clueless about this also, but relatively few.
VPNs are an easier way to use IPSEC than Opportunistic Encryption is - they're designed for only talking to machines you know and trust and have administrative relationships with, so it's a much simpler problem. As kmcmartin points out, FreeS/WAN has had this since early on (at least in combination with the standard firewalling capabilities.) In addition to letting ipsec packets through, you actually also need to allow UDP 500, which is the connection setup protocols, and you usually want DNS as well, depending on how you plan to identify machines that you're willing to talk to.
The debate about whether to do crypto at Layer 1, 2, 3, 4, or 7 has been going on for over a decade and a half. (Some people argue that crypto in the SSL/SSH sense is really layer 5 or 6, one of those OSI Session or Presentation Layer things that the TCP world doesn't worry too much about, but alternatively you can call it Layer 4 :-) Physical and Link-Layer crypto are fine for private networks - WEP is basically a Layer 2 crypto system which would be a good thing if it weren't badly thought out and badly implemented, and the NSA has been using Layer 2ish crypto on X.25 networks since the 80s, back when X.25 was the way you did international data networks. IPSEC has the advantage that it protects _all_ the communications between your machine and another machine, which can be really effective if that matches your communication patterns, and it means that the applications inside don't need to be modified to use crypto as long as they run over vanilla IP. Layer 4 cryptosystems like SSL and SSH are much more trouble - applications need to know about them, and they don't protect the machine against protocols that don't use them, but the operating system doesn't need to know, and intermediate routers and such don't need to know about it, so it can be more convenient to implement for applications that can use it. Layer 7 - things like PGP-or-S/MIME-encrypted email or encrypted file systems - is obviously much more customized, protects even fewer things, but sometimes it's the right way to go also.
A lot of credit also has to go to Netscape, who put encryption technology on everybody's desktop by including it in their browsers, which of course forced Microsoft to include it in IE as well. It's a different technical approach to attaching the crypto to the network, but you can use web browsers to downloaded encrypted files, read your webmail, etc., which is a large part of the problem space. Some of the core Netscape crypto developers were three brothers who also hung around Cypherpunks... The fact than a one-line ascii patch could "fix" the 40-bit crypto in Netscape and make it 128-bit was only partly technical convenience. And the "Develop and ship the code so people can use it" approach to protecting civil liberties is a lot more direct than ask-permission-first lawsuits, though some people went to extreme risk trying to keep their asses out of jail after doing so, like Phil Zimmermann. The FreeS/WAN people have also been taking this approach for a long time - it's developed entirely outside the US to avoid being subject to US crypto export requirements (John's a funder, and a user, not a developer for this stuff.)
Technology like this _has_ been rolled into popular software - the Internet stimulated awareness of the business need for crypto at around the same time that computers got fast enough to make it relatively practical. Virtual Private Networks are a different part of the IPSEC space than Opportunistic Encryption, since they're designed for letting approved people have a private conversation rather than letting just anybody access your machine, but they've been a standard business capability for a few years now - otherwise telecommuters would have to dial into dedicated modem pools, and if you remember running those, they were expensive and annoying to maintain. The IPSEC crew were an important part of the industry standards work, going to the various bake-offs to make sure things really interoperated, and having a free implementation that was vendor-neutral was a big help in getting everybody working together during the early still-flaky days. Middle-aged Microsoft operating systems had PPTP VPNs on them. They were terribly broken, and I think the WinXP stuff has real IPSEC built in, though that may only be XP Pro. And gradually there'll be better-working stuff there.
There are a lot of packages using SSL and SSH to do crypto
If your reference to streaming is to things like RC4, as opposed to OFB or similar DES modes, RC4-40 is of course toast, as demonstrated so thoroughly a couple of years ago that NSA gave up on making rules about it. The distributed.net folks apparently don't know when to quit :-), so they not only cracked RC5-56 and just recently RC5-64, but are going for RC5-72. RC4-128 is just fine, except if you use it for things it wasn't designed for (3 or 4 of the 7 main things wrong with Microsoft's PPTP were boneheaded-dumb misuse of RC4's requirements, and the WEP 802.11 folks found more creative ways to use RC4 for things it wasn't meant to do.) But as long as you use it the way it was designed to be used, it's strong enough, and it's just about the minimum-CPU crypto algorithm out there for general-purpose computers.
I'm not bothered that the most common SSL implementations do RC4-128 instead of 3DES - they usually have much more serious implementation problems (:-), such as not firewalling the hardware adequately, and they should also generally be using Perfect Forward Secrecy modes and often aren't.
The author's posting sounds like those people who troll about "NSA put a backdoor in PGP" and rot like that. Some of them are motivated by the fun of trolling, while some sound like they're spook sympathizers deliberately trying to undermine the public's use of crypto.
In sheenmaster@frob.us 's case, he's got a product on his website about his product FlameCrypt, which given his Slashdot posting I wouldn't touch with a 10-foot pole even if it did have documentation and the algorithms posted where you can get at it without registering on his site and/or downloading the program. Crypto people are concerned about privacy and about good documentation.... What I could find about it on Google\(tm was a reference to earlier versions that let you put in your own algorithms and "an algorithm generator program to automatically create new algorithms." Pure snake oil, which is consistent with his flame. Too bad - his web site had an entertaining counterflame about all the spelingg missteaks being intenshunnul.
*Minor exception - Elliptic Curve is 2**N, so it can get away with shorter keys than RSA or Diffie Hellman, but it's a newer theory and not everybody's convinced that a theoretical crack won't show up. It tends to have annoying patents on some of the versions as well, but it's convenient to be able to use 165-bit keys instead of 1024- or 2048-bit keys when you're trying to save space in packets or autogenerate the keys from passphrases. Also, the work factor I gave for RSA cracking is very approximate, and depends on what the best factoring algorithms are this year. But the basic principle has been constant for a long time, which is that a small linear or quadratic increase in encryption workload causes a basically exponential increase in cracker workload, and we've been on the pro-privacy side of that curve since before PGP first came out. Moore's law has meant that since PGP was good enough to use 512-bit keys on an 8086 in 1991, and 1024-bit keys on a state-of-the-art 386, back then, 2048-bit keys have been usable since about 1994 on a Walmart-quality PC, and your cellphone could have been running 1024 bit keys by about 1997 if the NSA and their equivalent thugs in Europe weren't pretending that they were forcing cellphone companies to use crippled crypto to keep the Commies from using it.
In general, the problem of "how do you have a secure conversation with a stranger?" in unsolvable. If you're communicating with somebody you know, you can set up pre-shared keys or X.509 keys or some equivalent and use them. We've had VPNs for a couple of years, and FreeS/WAN has done them, which address the problem of only talking to your friends. This stuff is relatively cool, except that most people don't have good control over their reverse DNS, even if they do have static IP.
.
.
(Are we supposed to add "you insensitive clod" now that somebody else is running the polls?)
The other alternative is to get different colors of interior case lighting so you can't tell that the flashing purple light is over the greenish board and the flashing near-indigo lights are over the teal-colored boards...
- The admaker company themselves --They get their site blacklisted heavily before and after some h4x0r k1dd13 scribbles it
- The site you're visiting --They get LARTed pretty fast also, and hopefully learn their lesson before Darwin gets them.
- Third parties, like banner services only worse. They need to find all kinds of bad things happening to themselves....
In general, people who design "user experiences" need to have some understanding of the user environment before selling their services. Otherwise they'll end up like that Pointcast service that didn't understand caching, which everybody really liked for a week or two before it was obvious that it trashed everybody's network performance, at which point sysadmins all blocked it. (Remember how "push media" was going to be the next cool wave of the future thingI've got DSL at home, so a 300K download is pretty fast, but it's still worth emailing the designers a copy of Mozilla so they can try out their product on a REAL browser... ("Here's my browser - try out your software on THIS!") and even making a couple of voice telephone calls to the company pushing them and its whois contacts. Companies that have 800-numbers sometimes really don't like getting their phones slashdotted with complaints, and if it happens to the customer as well as the supplier of this kind of adware, sometimes they get the hint.
Games are the reason for buying that new 7GHz machine with the gigabyte video card in it, and games are the hard-to-port reason for buying Windows, just as they're the reason for buying Gamez hardware platforms, because they're unique products (unlike Office, where a similar product running on a different OS is just fine.) So if good portability tools let game writers hang onto Windows a bit longer, fine, that still means that more of the important industry-driving products (:-) run on Linux as well.
Debian is a group of people who have SOFTWARE distributions, including a bunch of software distribution tools like apt-get. Usually people use their Linux distros, and use apt-get to get Linux updates, but they've also been working on other Unix-like distros, such as their GNU/HURD package. Unix in general has been intended to be a portable operating system, with applications that are portable (and often get ported to other operating systems, partly because C is a relatively portable language and partly because the models for interacting with the OS can be packaged in a variety of libraries to match the underlying platform.) So this one's using a *BSD kernel, with most of the same GNU and X and other non-GNU tools that they also run on Linux and HURD.
Tracing back from the mail server to the spammer is more the goal of Larry Lessig's proposal which Zoe Lofgren is putting into a Federal anti-spammer bounty bill. This initiative seems to be more targeted at doing something to the spammers once you've caught them, though the details aren't particularly clear.
It worked - there was lots of yelling and screaming, but in a month or so Netcom had closed their open email relays and gotten off the blacklist, and it got everybody's attention. In the meantime, I did what I had to do to get my email out, which was to use a different open mail relay at Netcom that the MAPS RBL hadn't noticed :-)
There are two fundamentally different things that ISPs can do with suspected spam
- Whole-ISP solutions that refuse to let it in the door at all (e.g. blocking all mail from open relays and suspected spamhausen, or using adaptive DNS responses so known relays think you live at 127.0.0.2 and don't even bother your sendmail.)
- Per-customer solutions such as tagging or discarding suspected spam once it's in the door. This gives the customer a lot more choices, but it takes a lot more resources from the ISP, including bandwidth and CPU. The first approach lets them get rid of most of the high-volume dreck cheaply.
I'm not bothered by either of these approaches; as I said, you can pick whatever kind of ISP you like. What is more of a problem is ISPs that block incoming mail without proper error messages. If you're sending legitimate email and it gets spam-filtered and the user never sees it, that's annoying, but at minimum, anything that gets rejected by the ISP's SMTP server should get an RFC-compliant reject response so you know to try contacting the recipient again using your hotmail account or whatever.But there are a couple of areas where US Federal laws could do as much good as harm, if they're written carefully enough to be effective as well as doing minimal collateral damage.
:-) No, the modem's not built into me, just into my computer. It took a long time before they actually reached me on the modem line, because normally if I was home, I'd have the (laptop) computer plugged into it, and if I wasn't home, I wouldn't know they'd called, but they eventually happened to call at a time that I didn't have the computer plugged in.
It seems to do a decent job of picking up dust, though some of the dust will get through and stick to the wall next to it. Cleaning isn't hard if you've got a bathtub nearby; you just pop the static element out and run hot water on it. A janitor's closet sink should work fine in an office.
Liquor dealers don't go shooting each other on the street corners, though people do rob liquor stores and drunks do get into fights. A day's worth of medical-priced opiates is cheaper than a half-bottle of bad gin.
Zucchini dealers don't go shooting each other, though there are the occasional Midwestern terrorist events (leaving bags of zucchini on other people's doorsteps during the growing season); marijuana's about as easy to grow as zucchini if you're not trying to hide it from the cops.
If we legalize drugs, street gangs may not stop carrying, but they'll mostly stop dealing, because you'll be able to get better-quality pharmaceutical drugs at the drug store and marijuana at the tobacco or liquor store, and at that point drug dealing turns into honest work, not significantly more profitable than selling flowers on the street corners except for a bit of low-markup business selling to minors along with selling them cigarettes. Might as well go back to stealing hubcaps.
Yes, it did say 802.11. There are times that's what you want, but since this seems to be a relatively expensive small machine rather than a cheap small machine, some of the market for it will be specialized applications like system administrators who need to be able to plug it in to various networks to measure things. You can do USB internet if you want, and USB2.0 is even fast enough to support a fast ethernet (as opposed to 12 Mbps max), but it's somewhat annoying.
Great. Not only will you have the RIAA trying to bust you with a DMCA lawsuit because it's an MP3 player, they'll hire the BATF to do the bust instead of some wimpy process server! Yes, Mr. District Attorney, it violates the California ban on Scary-Looking-Weapons and it's Infringing Copyright, so we want you to go for the extra-5-years penalty for Using a Gun To Commit a Crime"