Last Call Review of draft-ietf-lamps-e2e-mail-guidance-14
review-ietf-lamps-e2e-mail-guidance-14-secdir-lc-kaufman-2024-03-08-00

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