Proposal: PICS Defeater w/ Encryption

Pedersen writes "Here's an idea that I've been tossing around since the info on PICS came about, and I wanted to see some feedback about it. Basically, there is a way to get around PICS, using encryption, and some open source tools. First off, we have GPG now available to us for generation of public/private key pairs. Using GPG, we can set up key servers which are all tied together, which also have the capacity to sign keys (rather like VeriSign will sign keys, so can these). This would have to be a free service to encourage its use. In addition, the service would actually attempt to verify that submitted public keys belong to whom they say they do (ie: You can't create a key, and claim it's mine). You get the idea. The service has to find a way to get as many key servers as possible out there to hold signed public keys.

While this service is getting off the ground, these same keys need to be incorporated into a few other projects. These include S/WAN, Apache, Mozilla, ssh, and several MTAs/MUAs (sendmail, etc). This would allow for these various programs to automatically get public keys for individuals from the keyservers, encrypt the data to them, and send it down the wire to them with a nice innocuous rating. Quite probably, the easiest way to accomplish this is to develop a library which can check against GPG public keys.

Oh, and I'm sure many of you are asking why to get this done to the MTAs as well. A quick configuration option after this is incorporated would be to only allow connections from trusted hosts (ie: Their public key must have been signed by a trusted service). Combine this with a service which verifies the user's identity, and anonymous spam could become a thing of the past. Registered spam is still a problem, but that can at least be filtered out and reported very easily.

I've chosen the tools I mentioned because of the fact that, to the best of my knowledge, they are all true Open Source tools which can be used by us. Furthermore, if they're done right, the tools which interact with the user directly (ie: Mozilla, MUAs, etc), then these same tools can be ported to multiple platforms with a great deal of ease, allowing even Windows users, Mac users, and other OSes users to gain the same benefits.

I'm not sure if this is a feasible idea, though. Can such a project be undertaken in a short enough amount of time to short circuit any of the results of this conference in Munich? Is there enough interest in doing so?

I would suggest the following be done in this order, if so:

1. Get the code out of gpg and into a library which can be easily attached into any program, allowing members of other open source projects to begin planning for their code to use public keys and encrypted connections.
2. Get the code out of ssh to provide encrypted communications over a given socket, and put it into a library in the same fashion as the gpg library. As a side note, it may be desirable to put these two pieces of code into the same library.
3. Get code for key servers going which can accept gpg public keys (and their accompanying signatures), and also has the option of being restricted to accepting keys which have been signed by specific signing services.
4. While the above code is being ironed out, begin the process to set up the trusted services. This will include generation of keys, setting up ultra-secure computers to hold them (ie: Physically disconnected from the internet, etc), and decide what proof of ID will be required from users.

Well, that will about cover my thoughts on what should be done. If this is a desirable thing, then I am quite willing to be the organizer behind it all, though I will need help (for instance, sites which can host keyservers, library code, etc)."

I think Pedersen's idea is interesting, and I'd like to see what others think of it. There were several good suggestions for PICS-defeating systems in the comments on the two PICS articles - perhaps the authors can resurrect them here, and the community can decide what approaches have the best chance of success and are the most feasible to implement. -- michael

Comments

Extremely complex!

[Seth Finkelstein]

The infrastructure of public-key exchanges and
keyserving is still in its infancy. No-one has
succeed in scaling it to anywhere NEAR the size
of the Internet. That's just ONE problem. How
familiar is a nongeek with creating a key and
registering it? How many servers would be needed?
Just think about it. There's no magic crypto-fix.

- The Boston Lunatic

Re:Extremely complex!

[Pedersen]

Agreed, extremely complex. But not, by any means, intractable. Keyservers, at their heart, need only serve as much functionality as web servers. Because of the size of the packets which need to be transmitted (even some of the largest keys would be still be smaller than the average webpage), bandwidth would not be an issue worth considering.

Scaling, while an issue, is not as big of an issue as it is made out to be, I don't think. People are already used to searching on the web for a webpage. Extend this functionality to include searching the keyweb for the key you seek. Nobody said the process had to be 100% automatic (not yet, anyway) While it would take time to build a sufficient network of keyserves, I think it could be done. And, in the end, time is on our side with this issue, if we start now. If we simply start sending all of our emails signed (and encrypted, where possible), people can start to get used to the idea, and will ask questions. If we answer intelligently, we can get them willing to do the same thing.

As for how familiar is a nongeek... Currently, it's a pain in the rear to generate a key, get it distributed, etc. However, it doesn't have to be that way. A few simple installation wizard type of programs, and people can be merrily generating their keys and getting it registered. Signed is almost as easy after that.

Please, feel free to reply. While I'll admit to not being an expert on all the necessary ideas to make this work, I believe it CAN work, and would be the easiest way to defeat the whole PICS system, assuming we are too late to stop it from being implemented in the first place.

Re:Extremely complex!

[Greg W.]

If we simply start sending all of our emails signed (and encrypted, where possible), people can start to get used to the idea, and will ask questions. If we answer intelligently, we can get them willing to do the same thing.

This leads back to an issue that was raised recently on the main slashdot -- is there a good newbie explanation of cryptography somewhere on the web which can be used as the answer to the questions you're encouraging? Something that you could give to a completely non-technical person (your mother, or a WebTV user) which goes over the most basic concepts without going into enough detail to scare them off? (I guarantee you, as soon as you mention prime numbers or modular arithmetic, their brains will shut down. There must be no math at all.)

Re:Extremely complex!

[Pedersen]

None that I know of. But maybe it's time for me to start putting something together.

I'll write up something tonight, and submit it to Slashdot in the morning. It may take a few days, but it'll (hopefully) be posted, and people can begin to tell me where this idea really needs work.

Re:Extremely complex!

[Pedersen]

I got the file made, but unable to post it due to a lovely firewall at work. So, I'll post it from home tonight, and give the URL once that's done.

What about anonymity?

[Anomie-ous Cow-ard]

If you aren't careful in implimenting this, your plan will remove all anonymity from all communications on the net. For email it's not that big a deal, since anonymous email is already difficult without using the specialized relays for this purpose. But would you really want every website you visit to know who you are and exactly which pages you've ever looked at? Even if your key didn't contain a name or any other personal information, it is still a global unique identifyer that would make targeted advertisers' jobs infinitely easier.

You could possibly design web servers, anonymous ftp daemons, and other one-to-many services where anonymity is important to do something like this. My terminology may be a bit off, so bear with me. Note that gpg uses two keys for a message: the public-key cypher (e.g. DSA, ELGamal, RSA) is used to encrypt the one-time symmetric cypher key (e.g. Blowfish, CAST5, IDEA) used for the actual data.

1. User sends a request encrypted with the server's public key, containing the symmetric key expected for the reply (which may not be the same symmetric key used for this transmission) and the data request (http GET, ftp login, etc)
2. Server sends back the data, encrypted with the requested symmetric key and signed with the server's private key. Only the requesting client should know the symmetric key to be able to decrypt this. The signature can be used to verify that someone didn't just send back garbage while pretending to be the server, and that the transmission wasn't tampered with.

This way, the user gives no identifying information besides that already given with non-keyed http/ftp/etc.

-----

Re:What about anonymity?

[Pedersen]

Agreed, that is a decent idea, but has one possible flaw in it: The Man In The Middle attack. A server sits between you and your goal. You send out your request to connect to this server for the first time ever. The MITM intercepts your request, re-encrypts your data to the server, and receives the response from the server, stores it, and then sends the server's response on to you.

You won't see the difference, or know that it's happening, but your every move is being recorded, with even less anonymity. Translation: Even worse than before.

However, as an option, if all servers ALSO had signed keys which could be checked, the mitm could be eliminated safely. This technique would also allow people to maintain their current levels of anonymity (which, while very low already, don't need to be reduced further.

Explain...

[Anomie-ous Cow-ard]

The MITM intercepts your request

The MITM would have to either have the target server's private key (in which case you're screwed anyway), or be in the middle of your connection to the key database as well (like DNS spoofing, this would be key spoofing). Otherwise, he couldn't see the contents of your request (e.g. "GET /index.pl HTTP/1.0") and so couldn't send you back the proper data.

However, as an option, if all servers ALSO had signed keys which could be checked...

Wouldn't they already have signed keys, specifically the ones you used to encrypt the inital transmission?

-----

Re:Explain...

[Pedersen]

Not necessarily under the original proposal. Under the original proposal, only people have signed keys. Now, though, I can see where servers also need to have them signed.

And yes, I will freely admit that the idea needs work. But I wouldn't have posted the idea at all if I wasn't willing to work on it.

Easier solution (with anonymity)

[Gleef]

As earlier posters have indicated, the solution is both too complex and destroys anonymity. Here's another idea, it's very simple, and it improves anonymity.

Take Squid. Modify it to strip PICS information from any pages read through it. Run it on a decent box with a decent connection in a privacy friendly area. Better yet, have many people each run one or a few. Run some of them on alternate ports.

Anyone, using most existing software, can point their browser to one of these servers as a proxy. Free software can be modified to only bug the server when it gets a page blocked due to PICS restrictions. Some of these proxy servers might be set to only support the friendly browsers.

Your ISP won't see any PICS headers indicating naughty sites, so it won't filter anything from you. It's simple to implement, doesn't require authentication, works with most existing software, and actually improves anonymity, since the target site will see the HTTP requests come from the squid server, not from your machine.

----

Re:Easier solution (with anonymity)

[Pedersen]

Actually, a failing of the idea is that once PICS becomes mandatory, sites which strip it out will be blocked. Effectively nullifying the entire idea all at once, and making the service useless.

Re:Easier solution (with anonymity)

[Gleef]

It is impossible to block all PICS-free data. Even if you can somehow figure out which webpages are missing PICS information, if the info goes over, say, the ftp port, there's absoultely no way of knowing to block the data.

As for the sites, the more sites that are out there, the harder it would be to block them all. Most ISP's wouldn't care enough to bother, they'll be doing the absolute minimum required to stay within the law.

----

NDS like distributed KEy Servers??..

[yod@]

I'm not a whizz at crypto.. (I barly got my own private public keys figured out) It seams like we have a good understanding of how to distribute DNS over the internet.. I wonder if that model could be applied to keyservers ?

Just a thought.

Re:NDS like distributed KEy Servers??..

[Pedersen]

Well, DNS can naturally be broken down into smaller databases. For instance, the .com db, and the .net db, etc.

Keys don't neatly fall into that category. Though you could use the email addressing on those keys to break it down, I suppose.

Better solution?

[Omniscient Ferret]

I might be replying to a bogus interpretation. I am not an expert, but I have read the Schneier book.
PICS is a rating system for web pages, apparently categorized by authors for the use of easily offended people who are afraid of the unmediated internet. Authenticated email has nothing to do with this whatsoever. You can get an page securely and anonymously right now.

Let me know how this sounds. We establish a proxy mesh, so that all unencrypted requests for controversial material hit the originating server from non-sensitive territory. We encrypt the connection from our browser to the proxy for untraceability.
SSL improves upon PGP/GPG for this purpose. If you are used to PGP terminology, read 'certificate' as 'public key', and 'certification authority' as 'someone the browser trusts.'

1. GPG/PGP is not a stream cipher. The proxy couldn't pass any part of the file on until it had received the whole thing. In contrast, a streaming cipher like SSL can work on data - and pass it along - as it flows in.
2. It is already in browsers. In Netscape 2+ and MSIE 3+, you even can add new Certificate Authorities; having Verisign sign your certificate is not strictly necessary, but still useful.
3. An implementation (with source) is available both inside and outside the United States. SSLeay is a freely available implementation of SSL.
4. It can handle other protocols. SSLeay has been used in a secure telnet application. See section 16.2 of the FAQ pointed at above for info; the link may fail due to spaces in the anchor name.

A couple of places are implementing secure proxies to normal sites (that is, encrypted connection from the browser to the proxy) - the forthcoming-source proxy with SSL added on by C. Scott Ananian (based on IANS by Brian Ristuccia) and the as-yet-unimplemented commercial Anonymizer.com service. I don't know about the identification verification systems in the tools I note below, but the Certification Authorities should block man-in-the-middle attacks nicely. Of course, no revokation procedures are in place in SSL, but I'm already up way past my bedtime here.

The Internet Junkbuster Proxy, Muffin and RabbIT are all filtering proxies, well-adapted to block PICS quickly. These could also anonymize well, to avoid signalling the browser locale to the webserver. Squid is adapted for speed and caching, but not-at-all for filtering; I doubt it has any hooks in the code for that.

Re:Better solution?

[Pedersen]

Well, the main point is not the cipher itself, but rather the public key infrastructure.

In order to use a public key for, well, anything, you must have separate public keys for each application. What I'm suggesting is dropping down to one public key which is easily used in all other applications.

Once we've gotten that far down the road, it's a trivial process to attach a stream cipher to it. Of course, for what it's worth, even a block cipher would work fine, since each block is, more or less, independent of each other block. While not technically true, individual blocks could be passed from server to client easily.

Basically, at teh heart of my idea, is the idea that all traffic which can be encrypted, will be encrypted.

Now, to try and address your points, one by one:
1) Already addressed the streaming cipher issue.

2) Very true. But I'm not talking about just browsers. Every program, every daemon, every connection, employs encryption under this idea. SSL is nice. I still will push towards GPG though, out of personal preference.

3)GPG is free, period. If we could implement a GPG/(SSH|SSL) library, then people could link against that, and get full encryption functionality without dealing with the internals much at all. GPG in this case provides the certificates/key pairs, and SSH|SSL provides the socket.

4) Well, in the purest sense, virtually all protocols which use TCP can be almost interchangeable, as most of them (all of them?) are based on text interchanges between machines. As such, SSL would work. SSH would work. Any protocol should be able to sit on top of TCP, and provide a reliable connection. Whether or not it's encrypted... That's another story :)

Encryption HowTo, v0.1

[Pedersen]

Well, as promised, here's the first version of my Encryption How To. It's available at
http://216.17.163.212/Encryption-HowTo.p df.

Sorry for the delays, and the format. The format is there because it's only 0.1.

Please be gentle with it, since I'm only on a 256Kbps RADSL link.