Nov01: How Did This Happen?

How Did This Happen?

According to the authors of the Internet Engineering Task Force's Privacy Enhanced Mail (PEM) specification (John Linn and Stephen Kent), S/MIME (Paul Hoffman and Russ Housled), and XML-Security (Joseph Reagle) Standards, those working groups explicitly discussed surreptitious forwarding, and yet deliberately left the flaw unrepaired. The committees accepted this cryptographic neglect for several reasons:

Optional coverage. All of the specifications allow senders to put the recipient's name, or the whole mail header, into the message body before signing.
Contextual repair. In the same way, the PEM committee's discussion explicitly decided that the message's context would usually solve the problem. For example, Alice's signed "Dear Bob" salutation would reveal any reencryption.
Out of scope. The PEM committee noted that surreptitious forwarding is a type of replay, and that no e-mail mechanism can prevent e-mail replay. Thus, to the PEM committee, it seemed inappropriate to worry about surreptitious forwarding of signed-and-encrypted mail.

More recently, the XML-Signature and XML-Encryption working groups explicitly decided from the outset to emulate S/MIME's security. The XML-Security working groups' specifications are intended to be accepted as strictly low-level cryptographic primitives and, for better or worse, these groups treat sign-and-encrypt security as "out of scope" — partly a user-education issue and partly a security-semantics issue.

It's hard to blame these standards groups for having made a cryptographic mistake. Clearly, they all worked in good faith to promote secure and usable technologies. Further, it's important to acknowledge how hard it is to write networking standards in general, in particular, mail-related standards. As hard as it is to design cryptographic security protocols, cryptographic difficulty is only a formal or mathematical affair, and is very different from the difficulty of designing workable networking protocols for real-world deployment. Clearly, each of these standards committees tried to codify a cryptographically correct protocol. The worst that can be said of these working groups is that they underestimated the subtlety of adding cryptography to their already burdened portfolio.

— D.D.

Back to Article