[secdir] Secdir review of draft-ietf-lamps-e2e-mail-guidance-14

[Charlie Kaufman <[e-mail]>]

Reviewer: Charlie Kaufman
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document includes implementation advice for designers of Mail User Agents that deal with end-to-end cryptographic protection of email. Such a document by its nature is never complete, and one could imagine periodic updates based on what people observe as common mistakes in implementations and based on what we learn over time about what techniques are effective and what are not.

Anyone with experience in deploying cryptographic protection of email would be doing our community a service by reviewing this document and suggesting additions based on their experience (though they might be doing a greater service by supplying input to the next revision rather than holding up this one). Because this document covers many aspects of user experience (in particular, how to display indications of cryptographic protection in a way that users can't be deceived by a fraudulent message that attempts to deceive a user into believing it has different properties than it actually does), most of the advice has to be considered advice rather than something that could demonstrate compliance because different mail user agents may have different display techniques available to them. The document is proposed as INFORMATIONAL. It nevertheless uses the MAY/SHOULD/MUST/MUST NOT language.

There are some recommendations that I disagree with, but none that I could claim are "wrong". In particular:

Section 6.2.2.1 says: "In all circumstances, if the reply message cannot be encrypted (or if the user elects to not encrypt the reply), the composed reply MUST NOT include any material from the decrypted subpart."

While I would agree that if a user receives an encrypted message, he should not cavalierly include its content in an unencrypted message he sends out (reducing the confidentiality implicitly requested by the sender), in my opinion this should not be disallowed for cases where it is the only way to act on the message. Instead, it should be allowed only if the user explicitly acknowledges he is doing so.

Section 8.2.1.1 says: "A conformant MUA that generates S/MIME certificates for the user MUST generate distinct S/MIME certificates: one for encryption and another for signing, to avoid possible cross-protocol key misuse.
**and**
A conformant MUA that imports such a PKCS #12 bundle SHOULD warn the user if the bundle contains an S/MIME certificate and corresponding secret key where the same secret key is used for both encryption and signing."

While it is good cryptographic hygiene to use separate keys for signing and encryption, it is another way security people make like for confusing for the ordinary mortals trying to use our systems. There are also advantages to using a single key for both purposes, and while it makes sense to recommend this pattern, in my opinion it should not be required and we certainly should not bother users with details they will not understand when someone makes a different design choice.

Section 9.1 says: "When sending a message, a typical MUA will store a copy of the message sent in sender's Sent mail folder so that the sender can read it later. If the message is an encrypted message, storing it encrypted requires some forethought to ensure that the sender can read it in the future."

Section 9.1 goes one to describe a number of different mechanisms for doing this. I would note that there are cases where it is valuable for a user to send an encrypted message that he is not capable of recovering once it is sent (though this should not be the default). I've referred to this as the "Amnesty International" case, where someone wants to be able to send mail in a way that the recipient can decrypt it but he cannot be forced to decrypt it should he be captured.

Section 9.2 says: "When encrypting a message, the sending MUA should decline to encrypt
to an expired certificate (see Section 8.1.1)."

In my opinion, this is an example of security people making life more difficult to try to enforce some higher standard. In almost all cases, enforcing expiration of certificates inconveniences people to a much greater degree than it makes them more secure. A warning seems much more appropriate in this case.

Section 9.2 says "The primary goal of certificate expiration is to facilitate rotation of secret key material, so that secret key material does not need to be retained indefinitely. Certificate expiration permits the user to destroy an older secret key if access to the messages received under it is no longer necessary (see also Appendix A.9)."

I would argue that the primary goal of key rotation is to prevent a compromise of secrets from continuing to damage the security of the system indefinitely. Conventional wisdom is to promptly forget signing keys but keep decryption keys indefinitely (unless there is some reason to believe that all messages encrypted with those keys will never be needed again).

Section 9.6 says "The most understandable approach for an MUA with an active user is to ask the user (when they hit "send") to choose between approach 2 and approach 3. If the user declines to choose between 2 and 3, the MUA can drop them back to their message composition window and let them make alternate adjustments."

I would argue that this is asking users to make a choice the users are not likely to understand, and that a come understandable approach would be to tell users that the message cannot be sent encrypted to some list of recipients and ask whether to drop those users to send the them unencrypted.

Section 9.9 says: "A conformant receiving MUA that encounters a message with end-to-end cryptographic protections that contain a subresource MUST either refuse to retrieve and render the external subresource, or it should decline to treat the message as having cryptographic protections. For example, it could indicate in the Cryptographic Summary that the message is Unprotected."

I would argue that it is common today to receive mail with external subresources, and MUAs typically first display the message without those subresources and only upon explicit user request update the display to include them. This seems adequate, perhaps with a reminder somewhere that the external subresources may have changed since the message was signed. Also, the Cryptographic Summary should indicate the dubious validity of the signature, but still indicate that the message was encrypted.

Section 9.9 says: "Note that when composing a message reply with quoted text from the original message, if the original message did contain an external resource, the composing MUA SHOULD NOT fetch the external resource solely to include it in the reply message, as doing so would trigger the "web bug" at reply composition time. Instead, the safest way to deal with quoted text that contains an external resource in an end-to-end encrypted reply is to strip any reference to the external resource during initial composition of the reply."

This advice will result in messages being modified in a way uncontrolled by the sender. I would think it better to give the sender the option of excluding them, fetching and including them, or forwarding on the reference.

      --Charlie