Will Price wrote:

In your model, the recipient automatically decrypts and then re-encrypts to a data recovery key -- even though end-user computers are likely to be insecure thus making this decrypt & reencrypt step rather specious at best.

The value of this security model escapes me -- if the receiver's machine is insecure, you lose, period. Please, let us assume that neither endpoint is controlled by an attacker. You are concerned that the recipient is re-encrypting with a key whose access characteristics are unknown to the sender. Now, for all the sender really knows, the recipient may be storing the message in the clear, or maybe putting it on a Times Square billboard. This is not a cryptographic failure. In your CMR system as well, the sender has no choice but to trust the recipient's integrity and data hygeine -- or to not send the message. The headers could contain a request as to the eventual disposition of the message, but there are never any guarantees.

As an actual data recovery system, it also fails fundamental tests. If I encrypt critical data to a colleague wiping it from my system after sending, then the colleague is incapacitated before receipt and processing of the message, the data can never be retrieved.

Forget bus-struck colleagues, think unreliable messaging -- if you do this and your e-mail is lost in transit, your "critical data" is lost. So don't do this.

A data recovery system must solve this kind of issue -- data recovery here means that from end-to-end the data is recoverable in case of emergency. One cannot ignore message transit time in this -- it can take days for a message to travel from AOL to the outside world.

I'm not seeing how transit time figures in here. Are you proposing to bypass it by sending in an emergency team to acquire the in-transit message from the AOL machine room? If you find this practical, you can even retrieve an un-CMRed message by putting the recipient on this emergency team. But as I said, this situation should never be allowed to arise. Data recovery means you can get the data. It doesn't specify which copy you get decrypt. For reliable transmission over an unreliable medium, the sender must not destroy the original until receipt has been confirmed; for stored-data recovery, "receipt" involves appropriate re-encryption. (A reliable medium simply involves shoving all of this down into the messaging protocol.) So reliable transmission can support data recovery, from one end or the other, without message recovery. You might ask what happens if both endpoints are struck by meteorites. If the data is critically important, it will have been replicated off the sender's disk. The bottom line is that no such data can be trusted solely to an AOL mailserver (of all things).

If you don't need data recovery, don't use it, but at least respect the people who do need it and need it to actually work at all points.

I'm no protocol designer, but I'd have more respect for this system if explanations for its necessity seemed to have been fully thought through. The issue of communications keys versus storage keys has been discussed before; I don't believe I'm raising any novel issues. Did PGP Inc. consider and reject stored-data recovery (if so, what were the good reasons?), or are we seeing a retroactive explanation here? -- Eli Brandt | eli+@cs.cmu.edu | http://www.cs.cmu.edu/~eli/ (on FCPUNX, cc'ed replies appreciated)