Rick Smith <smith@securecomputing.com>
Regarding the practical uses of e-mail key disclosure, let me include one from the guard/firewall world that I haven't seen mentioned yet:
We've been shipping products since 1994 that scan the contents of e-mail messages and reject contents that violate specified filtering criteria. Sites use it to block importation of viruses or other inappropriate attachments, and to block the export of improperly released information. Most of these systems have been sold to the government and use the Message Security Protocol to encrypt data. The system rejects messages that don't contain an extra key so that the firewall can scan message contents.
I'm not sure whether pgp5.5 has this ability to screen messages prior to reading, and also not sure whether it has the ability to snoop messages prior to sending built in. The basis is there for the functionality in the enforced second recipient, but I'm not sure whether the client, or SNMP management tools, or SMTP policy enforcer implement this functionality. I'd welcome clarification from PGP Inc., employees, or anyone in the US has tried the pgp5.5 software for business suite.
This violates the assumed requirement that the contents of an e-mail message must not be viewed by anyone except the message's author and recipient.
It does yes. And that demonstrates that the principle is achieving it's function in high-lighting areas of a design which could be used for GAK purposes.
However, it's a security trade-off that some organizations want to make for certain applications.
Absolutely. You should try hard though to see if there are any software hacks or protocol reorganisations you can do to make the system unusable for GAK, or as close to unusable as you can.
PGP's key recovery protocol isn't the perfect solution, but it would help resolve a big problem.
Where that problem is can messages be screen by processes? One solution if you restrict yourself to processes is to move the function to the client and scan after decrypt. This isn't as easy to integrate into existing MUAs but would be possible for fresh re-writes like pgp5.x clients. If you want ability for humans to scan messages manually as well, and you can't live with the modifications in the client, you can do this within the CDR design principles: Have all email received by the company encrypted to the companies public key. Have your virus filter/human screener check the email, and then pass on to user in clear, or pass on to user encrypted with users key. Actually this is more secure than your solution, because the client already has an in memory master key; and now you have one crypto recipient rather than two to blow your security for you by allowing inadvertent key compromise. For outgoing email, configure the mail client plugin to either send in plain-text, or to sign only (one hopes with non escrowed signature keys, else your MIL friends will be able to forge each others mail), or to encrypt to the outgoing filtering agent, and have the outbound mail hub filter, or forward to human screener content checking. CDR compliant. Has some extra resistance to GAK corruption. As an additional application of CDR anti-GAK principles you could do the small software hack of allowing the clients and/or mail filtering agents to only communicate with each other if the machine IP addresses look like they are on the same mail hub. Don't provide source. (I suspect your company doesn't anyway for this kind of app, or do MIL people like to inspect source?) So now your system has a number of extra protections against being used for GAK. They are not perfect, but you've done what you can, and it's a definate improvement over what you had before. However I'm not sure it matters for your application really whether it is GAK compliant or not. This is because your application sounds like it is mainly for defense contractors, and MIL or NSA type use. As far as I'm concerned that lot deserve GAK. Keep themselves honest :-)
To send mail through these systems, the users must be trained to include the firewalls as message recipients -- this produces a copy of the symmetric key encrypted with the firewalls' individual PKs. If a user forgets, then the message can not pass through. The PGP approach of warning or demanding another PK token would help solve that problem at least in simple cases.
You can acheive the same functionality by insisting on mail being encrypted for the firewall. Firewall can re-encrypt for intended user.
ObPolitics: Personally, I think it's too soon to tell if PGP's implementation would benefit the FBI in its pursuit of wiretapping keys. At most it might resolve whether such mechanisms are in fact a practical technology. I'm not yet convinced.
I think you have a point there and that it's not entirely clear how this would work out.
Also, if commercial sites have already co-opted PGP's recovery key for their own uses, it's not clear that the FBI will be able to use it for clandestine investigations. If they approach the site's IS managers to acquire copies of the firewall keys, there's a good chance a rumor will get back to the people being targeted for surveillance.
I don't think that's the way it will work. What they'll do is require SEC cleared companies to provide this key as a matter of law to the government. If cheating is detected the bosses will get prison terms. Then they'll slowly spread it from SEC cleared firms to other companies. Maybe Public companies. Then they'll create a reichstag fire FBI constructed publicity type cases; perhaps money laundering, or purported mafia front business as an example of a public threat from allowing companies to communicate without escrow. Individuals too, some terrorist cases, a few more large scale bombings. No problem. If PGP provided facility for multiple enforced extra crypto recipients, it would be even more GAK compliant, as companies could just put a NSA key into the recipient box. The CDR design principles also apply to standards. Standards are very powerful things. If OpenPGP requires capability to understand and encode to second crypto recipients which are not message recipients for conformancy, we are in trouble also because all clients will then be required to make GAK easier to enforce; the capability is right there in pgp5.0 and pgp5.5 now. If on the other hand the OpenPGP standard does not include the second non message recipient crypto recipient feature, then companies who do chose to do so must build up their own client base outside of the installed client base, because they won't be able to build GAK and have interoperability at the same time. (We'll see whether or not PGP argue for this feature to go in the standard in a bit, when the draft standard is released, and discussions commence). Also remember that another danger with GAK software is that your country might be too liberal for the government to get away with various things, but others aren't. We don't want to encourage civil rights abuses. In some countries saying non-government approved thoughts results in prison terms, torture, and painful death.
Also, I believe the overhead for separate eavesdropping keys would produce too clear a sign to everyone that the FBI is listening. There is no precendent for such a thing and even if it's adopted temporarily I doubt it will persist. People will notice, it it will make them mad -- it will show them that the FBI is indeed under everyones' bed. Even the FBI can't stand up against broadly based grassroots pressure. Of course, I've been wrong before about politics.
Well I hope you're right of course, but I feel PGP could do more to prevent the scenario I present above, which I feel is fairly realistic. I also hope I have provided some worked examples of the logic in applying the CDR design principles. (They are counter-intuitive sorts of principles to work with because they are all negatives: don't do this, don't do that, no recommendations as such on what _to do_. This is because what you do is explore the solution space outside of the restriction they apply on it. They are also strange in that it is unusual to see formally codified cryptographic property design principles which reflect entirely a political issue. Must me a first :-) Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`