Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

PGP works well to provide many key aspects of information security; message confidentiality and integrity, sender and recipient authenticity, and sender non-repudiation (the sender, who has digitally signed the message using their own private key, cannot claim that they did not in fact send the e-mail). However, one thing it doesn't seem to provide is recipient non-repudiation; the recipient can still claim that they didn't receive the sender's e-mail, when in fact it was received, read and understood.

Most measures in place to provide this are voluntary on the part of the recipient; they can choose to send a "read receipt" to the sender indicating they received the message. These are e-mails, and like any, they can be spoofed unless the receipt is digitally signed by the recipient as the original message was by the sender. Or, the recipient can opt not to send the read receipt. In some cases, some e-mail providers and some e-mail programs/plugins even allow a recipient to send a fake "undeliverable" response to the sender (this is a strategy for fighting spam; by making your address look invalid to the spammer, he's encouraged to remove it from his mailing lists).

So, two questions; first, is there any existing scheme that enforces mandatory recipient non-repudiation measures? And second, if there isn't, what might you posit as a workable solution to provide this as an extension to PGP?

Something I thought of would require third-party participation of some kind. Normally, a PGP -encrypted message includes the symmetric key, encrypted with the recipient's public key, both sent directly to the recipient. What if, instead, that encrypted key were sent to a trusted third party "key holder", such as the sender's "home" e-mail server, along with the recipient's public-key certificate? The key holder can be authenticated with its own public-key certificate, thus also allowing secure communication between all parties including the key holder. Then, the message sent to the recipient would include a "pointer" to the key holder and a nonce identifying the message.

In order to actually read the message, the recipient needs to get the key from the key holder, so the recipient crafts a request for the key, signed with their certificate, and sends it to the key holder. The key holder uses the recipient's certificate (which the sender had provided along with the encrypted message key) to verify that it is the intended recipient asking for the key, and complies. The key holder now has proof that the intended recipient received the message they were asking about and is attempting to read it, and can inform the sender of that fact. This is a pretty strong "read receipt", IMO; you can't prove, beyond a shadow of a doubt, that the message actually was read top to bottom, line by line, and its content understood by the end user, but you can at least prove that you led the horse to water.

Thoughts?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

There are several challenges in transposing the "read receipt" concept to the world of emails. An important point to make is that read receipts are legal weapons aimed at the recipient; they are meant to be used as proofs, during some litigation against the recipient, that he indeed received it and thus can be presumed to have been aware of the message contents. The recipient is then the attacker, the villain in our story. We cannot expect his full collaboration.

There are two distinct scenarios here: the recipient might be interested in the message contents, or he might not be (for instance, he might expect a legally heavy notification and will not want to touch it with a 10 feet pole).

Let's see what happens with classical mail:

  1. The sender (let's call him Stuart) wants to send an important message to the recipient (Robert), and wishes to obtain a receipt that, should the worst happen, will be flourished by Stuart's lawyer during a subsequent trial, as a proof of Robert's duplicity.
  2. Stuart writes the letter and trusts it into the care of the local Postal service.
  3. The letter ultimately comes into the hands of the postman (sorry, the mail-delivery person) who will knock at Robert's door.
  4. If Robert answers, he will have to sign a receipt, under the supervision of the postman. The postman will give him the letter until he has signed. If Robert is not present, the postman will leave a notice in Robert's mailbox, and Robert will go fetch his letter as the Post office; a similar signature procedure will take place there, with the office clerk.
  5. The receipt is again transferred back to Stuart by the Postal service.

The postman is rather central in the whole procedure. Let's see what he does:

Confidentiality

Until he has signed the receipt, Robert has no knowledge of the message contents. This whole process assumes that the Postal service is trustworthy and ensures total mail confidentiality over the entire transit of the message. This property does not translate well to emails, because emails may travel unencrypted over the wires; PGP encryption with Robert's public key would not help, because in our scenario Robert is the eavesdropper.

Simultaneity

In the classic mail scenario, when the postman faces Robert, the postman is the Master of Ceremony: he ensures that Robert will not get the letter until he has signed the receipt, but he also ensures that Robert will get the letter if he has signed the receipt. When Robert is on the verge of signing, the letter is already on the premises; there is very little risk of losing it. Even if a really freak event occurred (e.g. a stray dog deftly snatches the letter from the hands of the postman and runs away with it), the postman would know it, and cancel the receipt. Also, Robert, by signing the receipt, shows that he is awake, understands what is going on, and is generally in full possession of his legal abilities. All of this occurs under the eyes of the postman, who could testimony about the proceedings.

These characteristics allow the judiciary power to assume that if Robert signed the receipt, then he did receive the message. Reading the message is under his responsibility; Robert will be considered as having read it (if he wants to claim otherwise, the burden of proof will be on him).

Electronic communications do not allow for such simultaneity. In email delivery protocols, like IMAP, POP or all the Webmail reader engines, there are only two possibilities: either the the recipient first gets the message and then acknowledges reception, or the recipient first sends the acknowledge and then obtains the message (most protocols choose the former). An honest Robert would be wont to send a signed receipt for a message he did not obtain yet and might never obtain (he has no actual guarantee that the server on the other side will not crash at that exact point); a dishonest Robert will arrange for never sending the final acknowledge, so that he could claim that his computer crashed at the wrong moment.

One partial solution is to have a trusted reliable delivery service -- a virtual postman, really. That is a service which will be imbued with all the official blessings that can be bestowed upon an administrative organization by the State; its mission is to deliver messages, but also to keep copies for a long time (say, three months). Honest Robert would agree to send a signed receipt to the Virtual Postman because he trusts that if the VP sent him a notification, then the message exists, the VP will not lose it, and he will be able to obtain it again from the VP even if his computer catches fire and he has to buy a new one. Under these conditions, a signed receipt before delivery can be legally required from Robert. This potentially fixes the technical issues of Robert obtaining the message first. But it requires a trusted VP.

The system you describe with the message key and the nonce is of that kind; the "sender's home e-mail server" plays the role of the trusted VP. But bear in mind that the VP must be trusted by both Stuart (Stuarts need the VP to keep the message from Robert until the receipt is duly signed) and Robert (Robert needs the VP to guarantee the delivery of the message, otherwise he will not sign the advance receipt).

Signature

To have any legal validity, Robert's signature on the receipt must fulfill the characteristics required by the Law. This depends on the country and its legal framework. For classical mails, the signature's power is not really in the squiggly line that Robert draws on the paper; it is known that some good con-artists can forge signatures, and, anyway, simply verifying that the signature is correct requires training. The real force of the signature comes from, again, the postman. The postman is a witness: he saw Robert signing. Refusing to recognize one's own signature is a serious offense, which is often punished with much greater severity than whatever a letter could entail.

In the world of computers, there is no witness. Robert could claim that his computer caught a virus and was under the control of someone else; the legislator cannot realistically enforce a requirement for all citizens to have virus-free computers. If the signature mechanism is of the asymmetric cryptography persuasion, then Robert could claim that the key is not his. This is especially true of decentralized systems like PGP and its Web of Trust: at one point, I counted no less than five distinct PGP keys bearing my own email address and uploaded on key servers, none of which being mine.

For any legal value attached to the receipt signed with an asymmetric algorithm, the corresponding public key must be provably bound to the signer's legal identity. This requires a lot of legislation and a State-operated (or at least State-subsidized) PKI: vital records and citizenship are, by definition, a monopoly of the State. I seriously doubt that a State would use the OpenPGP format for that; this is more a job for a hierarchical PKI, for which OpenPGP has no specific support (hierarchical PKI is about delegation of trust and power; this entails a lot of details which can be seen in the complexity of X.509, which tries to deal with it upfront).

Evasive Maneuvers

Robert may try to "play dead". This is hard to do with classical mail: you have to avoid the postman, hide when he rings at your door. You must not confront him because he is, as we saw, a presumed trustworthy witness. Positively refusing to sign the receipt is incriminating: it shows that you are aware that officially reading the message contents may have consequences. The bottom line is that playing dead with classical mails often equates to forfeiting mail reception altogether; this is not a ultimately tenable situation. All Roberts must yield, and sign the receipts, because the alternative is to figuratively cross the sea and then burn their vessels.

There is no such thing with emails. An email address can be dropped, since new ones are just free. It took me some effort to actually maintain my primary email address since 2001. Also, if I receive a notification telling me that an important message awaits me on some server somewhere (that I did not heard of before), then I can ignore it altogether: what does this server matter to me ?

(For a substantial proportion of the population, the classical mail model could be transposed to Facebook: Facebook could be the postman, forcing the recipient to either sign the receipt, or totally abandon Facebook, an unthinkable eventuality for the millions of addicts to that site.)

Summary

This is a hard problem for which no solution exists yet; the technical tools are ready (e.g. asymmetric signature algorithms), but it also needs some infrastructure which will need official support, will be expensive, and won't be of any use until is has become so important that it cannot be ignored. This looks like a problem which will not be solved any time soon.

share|improve this answer

first, is there any existing scheme that enforces mandatory recipient non-repudiation measures?

Portal based encryption products such as Sagava, Zixmail, and Proofpoint Secure messaging should get you close to your goal if not do everything your looking for. They operate by replacing the outbound message text with a hyperlink to a HTTPS portal that a user must login to view and read the message. Since the server is controlled by you, and each URL is unique per message, the message logs would be able to track that the message was read.

The main problem is usability, since each message has to be read on a variety of BYOD devices the end users often have trouble reading messages that use Java or a variety of other means.

The next problem with PBE is phishing, where users receive a message that looks similar to a legit PBE message and could steal the username and password. With this information the attacker could assume the identity of the user and read your email.

Another problem is that it's bad practice for an email company to encourage users to click on an HTML page within an email, or a hyperlink to read a message... this is one of the easiest ways to get a virus on another person's machine due to browser zero day exploits.

And second, if there isn't, what might you posit as a workable solution to provide this as an extension to PGP?

I'm interested in any PGP or SMIME extensions you become aware of, but as of yet, I don't know of any.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.