Blayne Sucks

Ordinary Men by Christopher R. Browning is a book on Nazi Germany’s Reserve Police Battalion 101, which participated in the Holocaust. The primary discussion in the book is on how a group of ordinary, middle-aged Germans became mass murderers. He attempts to understand how this transformation took place, and he uses insights from the Milgram experiments and the Stanford Prison experiments. However, he is quick to point out in the forward of the book that “explaining is not excusing; understanding is not forgiving.”

The book was recommended to me by Lucas Layman after a discussion on the importance of the human element in computer security led to a discussion on the Milgram experiments and the Stanford Prison experiments. Certainly there are many elements of computer security and computer crime that can be better understood through studying human psychology. For example, the simple fact that as the men of Reserve Police Battalion 101 were removed from direct participation (e.g. pulling the trigger themselves) to indirect participation (e.g. leading Jews to death trains) they were more easily able to cope with their actions psychologically. Similarly, computer crime is easily disassociated because of the impersonal nature of dealing with computers rather than humans. However, after reading the book my strongest reaction has been broader than just computer security.

When I was in high school I had to read quite a few books on the Holocaust. It seemed that every year we read a different book on the subject, and I tired quickly of the extremes that were pushed. Nazi Germany in general and Hitler in particular have become famous for being the most extreme extreme. This is perhaps best identified by Godwin’s Law.

Ordinary Men suffers from over-extremism to some extent as well. For example, Browning causally refers to the Holocaust as the “most extreme genocide in human history” without offering much in the way of proof or comparison. The number of Native Americans systematically killed by Europeans and the number of Russians killed by Stalin’s regime could each easily exceed the numbers of Jews killed by the Holocaust. The rate of killing in Rwanda could easily surpass the rate of killing in the Holocaust. The brutality of groups like the Khmer Rouge and leaders like Genghis Kahn could be argued to be greater than that found in the Holocaust. Is it even possible to classify something like the “most extreme genocide in history?”

My point is that our only reaction to events like these cannot be the emotional one; we must attempt to understand why and how these things happen so that we can learn from them. We aren’t good at rationalizing emotions, and we are rarely able to draw objective conclusions based on them. However, if we can take a look at some facts, then we may be able to learn important lessons. For example, before the brutality caused by Nazi Germany and in former Yugoslavia, we see extreme hyperinflation. Do we know anywhere else in the world where that is happening right now? I think so. This is something to be concerned about.

More generally security is a field that suffers from extremely emotional reactions. The air travel response to the September 11th attacks is a good example. How many of these responses have been the result of reason rather than emotion? How many of them have actually improved airport security? These are questions that we will probably continue to struggle with for years because of the highly charged emotional response most Americans have to the September 11th attacks.

On the whole though, Browning does a good job of ensuring that we don’t view the people of Reserve Police Battalion 101 as caricatures of themselves. As a result, there are many lessons to be learned from this book. The Holocaust should not be thought of as an abstract evil thing, but instead as a real consequence of human plans and actions. As Browning says, “Ultimately, the Holocaust took place because at the most basic level individual human beings killed other human beings in large numbers over an extended period of time.” The book offers an objective take on how ordinary people are capable of such a thing. I found it to be a very worthwhile read.

I know many readers of this blog also follow ThePrivacyPlace.org, but I wanted to ensure that those who simply follow this one where aware that there is a research survey currently being conducted at ThePrivacyPlace.org. I encourage everyone to participate as this is an excellent way to contribute to academic research and our understanding of online privacy concerns.

Cross posted from ThePrivacyPlace.org:

ThePrivacyPlace.Org Privacy Survey is Underway!

Researchers at ThePrivacyPlace.Org are conducting an online survey about privacy policies and user values. The survey is supported by an NSF ITR grant (National Science Foundation Information Technology Research) and was first offered in 2002. We are offering the survey again in 2008 to reveal how user values have changed over the intervening years. The survey results will help organizations ensure their website privacy practices are aligned with current consumer values.

The URL is: http://theprivacyplace.org/currentsurvey

We need to attract several thousand respondents, and would be most appreciative if you would consider helping us get the word out about the survey, which takes about 5 to 10 minutes to complete. The results will be made available via our project website (http://www.theprivacyplace.org/).

Prizes include $100 Amazon.com gift certificates sponsored by Intel Co. and IBM gifts.

On behalf of the research staff at ThePrivacyPlace.Org, thank you!

I was going to wait until Dan Kaminsky announced more details about this flaw at the Black Hat Briefings on August 6th, but Halver Flake’s recent post as essentially squeezed the toothpaste out of the tube on this one. Just look at what Dan has to say.

I’m not going to talk about Dan’s decision not to release the details of this attack as soon as possible or the merits of full disclosure in computer security. Although interesting, it is less interesting to me than the flaw itself.

I know not everyone who reads this blog is technically oriented. To those people, I encourage you to try and make your way through this (long) post. I will try to keep things as simple as possible and I can guarantee you that a better understand of this particular problem will not only give you a better understanding of computer security, but also a better understanding of how the Internet really works.

Let me take a few moments to provide some background. The Domain Name System (DNS) is the protocol that translates a website’s domain name (e.g. somebank.com) into the corresponding IP Address (e.g. 192.168.1.1). IP Addresses are used by routers and network infrastructure to deliver information from one place to another on the Internet. DNS has been around since the mid 1980′s. It is a critical part of the infrastructure of the Internet. When you type in a domain name or use a bookmark to visit your bank’s website, you are trusting that the DNS protocol will take you to the correct server and not to a well-designed phishing website that looks just like your real bank.

The recent flaw in DNS is a protocol-level design flaw, not a software bug. A protocol is merely a pre-defined set of steps done to achieve some objective. For example, when Alice introduces two of her friends, Bob and Chris, to one another for the first time, she would follow a social protocol of introduction. She may introduce Bob to Chris as her co-worker from the Human Resources department, and she may follow this by immediately introducing Chris to Bob as her friend from church. If Alice forgot to introduce Bob to Chris and Bob eventually had to introduce himself to Chris while Alice was standing there, then that failure on Alice’s part is analogous to a failure in a single piece of software. If there were a flaw in this protocol, then every introduction performed based on this social protocol would fail. That is the difference between a protocol-level flaw and a software bug.

Now we have gotten to the crux of the issue. There is a protocol-level flaw in DNS that allows a phisher to take over the actual domain name of the site that it is trying to imitate. This is a serious problem that led to an astonishing collaboration to patch the entire Internet. Even patching the entire Internet isn’t going to “solve” this problem. Why? Because the patches are just that: patches. The problem still exists in the protocol.

What exactly is this problem? (And here’s where I may lose anyone who’s not technically oriented, but I’ll try and keep this simple.) When a DNS server doesn’t know how to translate a domain name into an IP address, it asks another, more trusted, DNS server for the information. Of course, this happens quite frequently since any given DNS server can’t store all the correct DNS translations for the entire Internet all the time (and since these translations can change).

Each time a DNS server has to ask a more trusted DNS server for a domain name to IP address translation, it does so by providing a number called a Query ID (QID). Now, there used to be a ton of attacks based on these QID since they were sequential. This class of attacks basically consisted of an evil doer asking a DNS server to perform a translation on a domain name that it didn’t already have. The evil doer would then start sending forged responses with sequentially increasing QIDs. If the evil doer got the right one, a bad domain name to IP address would be cached. Once a translation is cached, most DNS software implementations will ignore other updates to that domain’s information.

There are many ways to poison a DNS cache. This particular problem was patched (not solved) by just not using sequential QIDs. If a random QID is used, then it becomes very difficult for the evil doer to respond before the real response arrives.

Another interesting way to poison a DNS cache is to send a fake resource record. This attack works because of a chicken-ad-the-egg problem that I deftly avoided in my earlier description of DNS. I said that when a DNS server doesn’t know the proper translation for a domain name, it asks a more trusted DNS server. How? How does it know a more trusted DNS server? Basically, it only knows trusted DNS servers by their domain name. So it has to resolve a domain name for the next step in the hierarchy. Let me give a simple example.

Let’s say you’re a DNS server trying to resolve checking.somebank.com and you don’t know how. Who are you going to ask? Well, you’re going to ask whatever domain name server is controlling somebank.com since somebank.com is the next step in the hierarchy. If you don’t know that one, you’re going to ask the .com root server. Of course, you would like to learn how to ask somebank.com how to resolve all of it’s subdomains (e.g. checking.somebank.com, savings.somebank.com, etc…) since that would be efficient. This is done through a DNS Resource Record (RR).

Although there are many kinds of DNS Resource Records, for this attack all you need to know is that when you make a query for a DNS translation, you can receive back an answer as well as an additional resource record that is intended to help speed up future queries. Now, it used to be possible to poison DNS caches directly with this because there was a flaw in the protocol that allowed these resource records to be totally unrelated to the original request.

For example, let’s say you’re a DNS server and you just sent out a query about checking.somebank.com. It used to be possible that you would receive a domain name to IP address translation for checking.somebank.com and an addition resource record telling you that you should cache ns.evildoer.com as a name server for future queries. This was patched (not “solved”) by requiring the additional resource records be related to the query. (Thus, you would only be able to get a DNS RR for a somebank.com name server.)

The most recent DNS protocol-level flaw is related to both the QID problem and the DNS RR problem. Here’s how I believe it works (and these details are already available to anyone with access to google and a few minutes):

1. Get a DNS server to look up a subdomain for the site that you want to compromise. For example, randomAAAAAA.somebank.com. The subdomain itself doesn’t really matter other than it shouldn’t exist.
2. Since the DNS server doesn’t have this domain name to IP address translation it will have to look up the answer. Now, the evil doer can’t reliably predict the QID since random QIDs are used. The vast majority of these lookups will correctly be answered by ns.somebank.com as non-existent subdomains with the right QID. However, the evil doer can still try and race ns.somebank.com to guess an answer.
3. The evil doer repeats step 2 and increments the random domain name every time. For example, the next domain name the evil doer might try could be randomAAAAAB.somebank.com. Since QIDs are just randomized and not cryptographically secure, the attacker may still have a mathematically reasonable chance at eventually guessing correctly and beating the real name server’s response. If that happens, then the real name server’s response is dropped and more importantly the attacker has earned the right to send a DNS Resource Record updating the name server for the bank. (i.e. The attacker gets to poison ns.somebank.com and make it point to their phishing site.)

It’s clever. It’s not easy to solve, so we’re going to play the patching game again and people are rushing to patch their DNS servers. Now, this post is not going to talk about the losing battle that is penetrate-and-patch. Although it would be fun to rant, that debate is no longer interesting since all the smart people are on the same team.

So why is the flaw (and perhaps computer security on the whole) interesting? The assumptions involved. Professor Spafford has a great quote about computer security and assumptions:

Finding vulnerabilities is simple; discover the assumptions a developer made, ad then violate those assumptions.

People have become accustomed to DNS working. They assume it will work. It’s not just users, but also developers that do this. Let’s take one example: OpenID.

For those who don’t know, OpenID is an identity system that enables users to store their identity information in one place. Instead of having usernames, passwords, addresses, and other account information stored separately at amazon.com, ebay.com, flickr.com, etc…, users would be able to store it (and update it) all in one place. It’s a really neat idea that could eventually provide useful services and save real people time. However, it was designed with the assumption that DNS just worked.

Kim Cameron points this out on his blog, but I think the best summary of the problem is by Tim Anderson:

Note that Cameron is not opposed to OpenID. Apart from anything else, he recognizes that this may well be the beginning of an identity revolution – part of a process, at the end of which we get a safer, less spam laden, less criminal-infested internet.

At the same time, he’s right. The whole OpenID structure hinges on the URL routing to the correct machine on the Internet. In other words, DNS. Now do some research on DNS poisoning. Scary.

Now, it strikes me that you can largely fix this by requiring SSL connections. In other words, have the OpenID URL be an https:// URL, and have the relying party (the website where you want to log in) check for a valid SSL certificate. Note thought that SSL must be used at every stage. OpenID lets you use your own URL as the identifier, but redirect to another OpenID identity provider. Both URLs must use SSL to maintain integrity.

Scary indeed. The OpenID developers have assumed reliable DNS. Now, Tim’s probably right that encryption is the solution to this problem, but I don’t think SSL would work. Even if there is a certificate for the site, most browsers fail to properly inform users what it means when an SSL certificate has changed or isn’t there now. Plus, people are trained to use the domain name and trust that it works.

So how can encryption help? Well, I think DNSSEC and IPSEC (or IPv6) would actually solve (not patch) the problem, but designing better protocols hasn’t been the real issue. DNSSEC and IPSEC have been around for a while. The problem is adoption. No one uses these protocols just like no one uses PGP for encrypting their email.

Metcalfe’s Law is holding most people back since they don’t want to be the only ones using the “other” network. This is another great example of why “road” or “highway” analogies don’t work for the Internet. If this were a pothole or even a collapsed bridge, we could fix the problem properly without really affecting most people. However, since this is the Internet, we can’t actually solve this unless everyone agrees to stop using DNS.

So we’re going to continue to see problems with old infrastructure protocols like DNS. As a result, phishing will continue to be a serious problem. The only way this will stop is if there is a problem so big that the monetary incentive to avoid the problem pushes everyone to change. Who wants to guess how big of a problem that would have to be?

Yesterday Barack Obama was at Purdue University to talk about national security. You can read the text of his remarks here.

Purdue University may seem like a strange place to talk about National Security for many people, but this location was well-chosen for several reasons. First, Clinton won Indiana in the primaries and although the state tends to vote republican in November, Obama needs to continue to bring the democratic party together. Second, Sen. Evan Bayh (D-IN) supported Clinton in the primaries. He’s a very popular former governor of the state who’s father was also in the Senate. Being able to receive his support is important for Obama. Third, Sen. Richard Lugar (R-IN) is a foreign policy and national security expert. Although Sen. Lugar was not at the event, he was spoken of with high praise. Fourth, Purdue University is home of CERIAS, one of the best cyber security research institutions in the world. It makes sense to talk about national security in a state that has such an influential voice in that area.

As to the actual event itself, I strongly encourage you to read Professor Gene Spafford‘s write up of his experiences at the event. He gives an overview of Obama’s speech and each of the three panels that followed. It is an excellent read if you are interested in national security, politics or computer security. Although there are many quotable sections of the post, I will refrain from quoting it in the hopes that my strong endorsement of it will encourage you to read the whole thing.

CNN is running an article about a 22 year old woman who is facing a probable sentence of six years for identity fraud. There are a couple of things to note in this story.

First, their victims were friends and family. This is a common form of identity fraud. More than a third of all victims of identity fraud know the person who victimized them. Why? The answer is access. Friends and family are more trusting and their identity information is simply more easily available. It may even be easier for criminals to use since many vendors may be willing to look the other way for a daughter using her mother’s credit.

Second, the article quotes a federal prosecutor using the phrase “identity fraud” rather than identity theft. This is extremely important because it more accurately describes the crime. We already have laws on the books for fraud. Fraud has been illegal for quite some time. Yes, there are technological issues in catching the criminals, but the situation is far better than it was a few yeas ago.

Jim Harper describes the difference in detail in his book Identity Crisis:

Silence of the Lambs was a 1991 movie starring Jodie Foster as FBI Special Agent Clarice Starling and Anthony Hopkins as the notorious and devious supercriminal Hannibal Lecter. At the end of the movie, Lecter overpowers ad kills two guards in order to escape from a special prison that has been built for him on the upper floors of a building. He changes into the uniform of one of the guards, hides the guard’s body and poses as that guard, badly injured but clinging o life. To complete the deception, Lecter tears the guard’s face off and places it over his own. The police wheel Lecter out of his prison on a gurey, underneath that gruesome mask. This is identity theft. Lecter has taken a key identifier from the dead and mutilated guard, who will never get it back.

Obviously, simply using an identifier is far different than stealing one. It is nice to see that the federal prosecutors are using the correct terminology and that it is making its way into the mainstream press.

Recently we have seen several interesting developments in Mac OS X Security. Apple published a Leopard Security configuration guide (pdf) for experienced Mac OS X users. Apress published Foundations of Mac OS X Leopard Security. (Slashdot review here.)

However, I think the most interesting development has been the discussion of a SUID vulnerability by Matasano Chargen, among others. The vulnerability can be easily fixed by:

sudo chmod -R u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app

Along with the announcement that most of the work on the next version of OS X will be under-the-hood improvements, the discussions of what improvements Apple should make to OS X Security have been thriving. In particular, I like Dino Dai Zovi’s editorial on what improvements he would make.

Dino lays out five specific improvements he would make:

• Real ASLR (address space layout randomization). Library randomization with dyld loaded at a fixed location just doesn’t cut it.
• Full use of hardware-enforced Non-eXecutable memory (NX). Currently, only the stack segments are enforced to be non-executable. Welcome to the new millennium where buffer overflows aren’t only on the stack.
• Default 64-bit native execution for any security-sensitive processes. I don’t particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, Mail.app and just about everything else that has security exposure to run as a 64-bit process. Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
• Sandbox policies for Safari, Mail.app, and third-party applications. Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications. I love the scheme-based policies, by the way.
• Mandatory code signing for any kernel extensions. I don’t want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk. Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate.

Overall, this is an excellent list with one glaring omission: improve FileVault. There are many things that could be improved in this area, but I think the first two that come to my mind are integration with Time Machine and the ability to configure encryption for individual folders (other than the home folder) or entire disks. There are other, more technical problems with FileVault (such as the use of CBC mode encryption), but I think these are largely less important than living up to Apple’s reputation for making things easy to use. Right now, FileVault is not easy to use with Time Machine and it doesn’t serve the needs of those who need full disk encryption or those who really only want a few folders to be encrypted.

I would also like to pick a tiny nit on Dino’s list. I think Mandatory code signing for kernel extensions should be something that by default is enabled, but could be turned off manually as a part of the System Preferences by a user. There are still people who want the freedom to do whatever they want with their computer and although this may mean that they have enough rope to hang themselves, they still deserve that freedom.

Here’s a really nice down-to-earth screencast of the new features in Firefox 3, which will be released this month. I found this through Slashdot, but it is actually quite straightforward and you shouldn’t need a technical background to understand what’s going on here.

The screencast shows a nice overview of the new Firefox, but I wanted to focus on two very important security features that are new in Firefox 3: Website Identity and Malware protection. The website identity feature uses certificates and previous visits to inform the user who runs the website and whether or not the user has been there before. This is critical information that can both improve user confidence and prevent phising attacks.

The malware protection feature attempts to prevent sites from taking advantage of flaws in the browser or add-ons. This feature is similar to the Phising protection added in Firefox 2, but they are also integrating virus scanning and malware protection into the download manager.

The screencast doesn’t talk about Mac features, but since I use a Mac, I will mention the big ones briefly. Firefox 3 takes on more of the Mac user interface conventions when installed on a Mac. One of their big pushes was to make sure that their browser was a native application for each operating system it installed on, so this actually applies to Windows as well. Also, Firefox 3 has significantly improved memory management and speed on the Mac. This was improved across all operating systems, but it was a serious complaint in the Mac community because Safari was so much more efficient than IE or Firefox. For the interested, Daring Fireball has a much more detailed coverage of Firefox 3 for the Mac.

Obviously, I can’t cover all the features in a new release of something like Firefox with a single blog post, so if you want more information I recommend checking out lifehacker’s top ten list of new Firefox features. For those who are of a more technical persuasion and wanting more information, you can check out the Firefox 3 Product Requirements document here. Also for the serious geek, check out this post (somewhat old now) on Firefox 3 Memory Usage improvements.

[Edit: There's an excellent "Field Guide to Firefox 3" post here that explains all anyone would want to know and more about the new version of Firefox, which is released tomorrow, June 17th.]

Although I’m sure this is old news by now (I apologize – I have been extremely busy the last couple of months), I did want to post briefly to say that I was announced as the winner of Bruce Schneier’s Third Annual Movie-Plot Threat Contest. As I posted in that thread, I am surprised and pleased to have won. And honored. It’s nice to get a hat tip from people whom you respect and admire.

I encourage you to check out the other entries, which are extremely good. When the finalists were announced, the comment-based voting was very, very close. Here are the other entries:

• DNA adulteratometer
• SOS device
• Anti-laser-pointer eyeglasses
• “Alertness alert”

Lastly, my winning entry: Toothpaste test strips.

Ravan, one of the commenters in the announcement thread, pointed out that the FDA has a FAQ on toothpaste, which is rather interesting. Obviously, I based my entry on the fact that there was a recent scare and actually quite a few deaths related to contaminated toothpaste. I think these peripheral fears are exactly the kinds of things that can cause a lot of unnecessary terror on the part of the average person who simply doesn’t have time to keep up with the myriad of things out there that can cause harm. Even though no one in the United States died, the story about the contaminated toothpaste received extensive coverage.

The whole thing had a sort of Tylenol murders feel to it. What is it about human psychology that makes us so afraid of this type of threat when statistics can show other threats are far more dangerous? Bruce Scheier has been investigating this pretty regularly on his blog and I encourage you to read his essay on the topic if you are curious.

Although Ed Felten has recently gotten tons of press about his research group’s recent analysis of breaking hard drive encryption, I wanted to talk about some research that he’s done previously on electronic voting for several reasons. First, I mentioned voting in my last post. Second, I have blogged about electronic voting here before that. Third, it is an election year and seems pertinent. Fourth, I am still trying to catch up on some blogs that I follow and recently was able to watch Ed Felten’s presentation in the CERIAS Security Seminar series.

If you are unfamiliar with Ed Felten, I would like to provide some background. He’s a computer security researcher with extensive experience in authentication, secure Java programming, and digital rights management. He has recently also become a leader in analyzing security concerns relating to electronic voting. He is a fellow of the ACM and an EFF Pioneer Award winner. He is the author of a popular technology and public policy blog called Freedom to Tinker. He is also an excellent presenter.

His presentation for the CERIAS seminar is extremely good. I think it is probably accessible for those who are not well-versed in computer security terminology. Certainly, most of the talk is non-technical in nature. I strongly urge anyone reading this who has wondered just what the big deal surrounding electronic voting is all about to at least watch the first half of the presentation. It is an excellent introduction into the amazingly insecure fashion by which elections are held in America.

He talks about the history of electronic voting, some of the legislation that may affect electronic voting, the goal of verifying an election and how their research group has approached the problem. I’m not entirely sure that the importance of the problems can really come through in a sterile environment such as an academic presentation, but he certainly does a great job of motivating these problems on his blog. For example, the pictures on his blog he takes of unattended voting machines prior to election day. Of course, like any true academic, he provides references to their work so that you know where to look for more information if you are interested.

At the end of the talk he is asked a question about possible cryptographic methods that would allow a voter to obtain a receipt that they could later verify on a government website. I’m not entirely sure I like his answer. He says something like (Yes, I’m paraphrasing.), “There are attempts, but they aren’t ready for primetime.” This is a huge caveat and it almost seems to imply that the crypto isn’t quite there yet. Usually, it’s the humans that aren’t ready for the crypto. In this case there are some pretty interesting cryptographic schemes, and they lack the same thing most other cryptographic schemes lack: an easy-to-understand user interface. I’m sure Dr. Felten knows this and was just providing a concise answer, but if you are interested in more, I would read Dr. Rivest’s paper on Three Ballot Voting as a great place to start.

One of the most highly charged pieces of legislation that has been passed by Congress in recent years is the Protect America Act. Probably the only good thing about it is the sunset provision that ensures it will expire in its current form unless Congress acts to renew it or make it permanent. That debate will be soon; the act was extended yesterday for another 15 days.

I haven’t commented about this much because there’s been quite a bit of coverage of it in the mainstream media. If you have somehow managed to avoid that coverage, and landed on this blog (Hi Mom!) the 15-second summary of the Protect America Act is that it allows the NSA to skip the established process of getting a warrant to wiretap communications by using an entirely internal process of reviewing the need for the wiretap. The White House wants this legislation because they believe the current process of obtaining a warrant is too slow for present needs.

Furthermore, there will be debate on a second major initiative of the White House: retroactive immunity for the companies involved in recently allowing illegal wiretaps. The 15-second summary of this situation is that an AT&T employee blew the whistle on a secret room that was setup to see all the data sent over the Internet for AT&T and several other companies. There is a class-action lawsuit against the companies and the Bush administration would like to get them off the hook by making their actions legal after the fact.

If you would like a quick overview of the situation as of November to catch yourself up on what might be on the news in the next two weeks, check out this YouTube video:

There are many places to go for more information on these issues. The Center for Democracy and Technology has an excellent guide on the amendments. EPIC spotlights surveillance issues here. The EFF has more information on warrantless surveillance here.

However, the best resource and the primary reason I chose to make a blog post about this topic is the paper entitled “Risking Communications Security: Potential Hazards of the Protect America Act” by Steven Bellovin, Matt Blaze, Whitfield Diffie, Susan Landau, Peter Neumann, Jennifer Rexford that will appear in the Jan/Feb issue of IEEE Security and Privacy Magazine. If you only read one article linked from this post, the Risking Communications paper is the one to pick. Matt Blaze has a post about their article, as does Steven Bellovin.