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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Charlie--

Thank you for the detailed SECDIR review of
draft-ietf-lamps-e2e-mail-guidance!  I really appreciate your grasp of
the importance of the problem space and the motivation for the document,
and your engagement with the content of the draft.

Your notes about where you have some disagreements with the draft are
all very perceptive, and the editors struggled with each of these points
when drafting the document.

I'll explain a little more of the reasoning we used to reach these
recommendations inline below, including a proposed edit that i hope will
satisfy at least one of your concerns somewhat.  If you have any other
proposed edits, i'd be happy to review them, either for inclusion in
this draft, or in any future revision.

On Tue 2024-03-05 00:39:41 +0000, Charlie Kaufman wrote:
> 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.

This is in the section about an errant encryption layer; that is, the
incoming message is actually malformed.  Shuffling message parts to
produce a malformed message which then acts as an oracle during reply is
one of the themes covered in the EFAIL attacks.  A warning would have to
be pretty sophisticated to help the normal user make sense of -- not to
mention actually avoid -- these message splicing attacks.

Section 5.4, on the other hand, covers replying to a well-formed
encrypted message, and there it says:

    In this circumstance, the composing MUA SHOULD strip the quoted text
    from the original message.

Bron Gondwana's review
(https://mailarchive.ietf.org/arch/msg/art/34S0GcjJGZUqD_w0EHNDRbXbOME/)
suggested that user acknowledgement might be an appropriate step in that
case, and i'm proposing to make that the exception to the SHOULD case
for replies to a well-formed message in this change:

   https://gitlab.com/dkg/e2e-mail-guidance/-/merge_requests/12

The revised text for §5.4 would then read:

    In this circumstance, the composing MUA SHOULD strip the quoted text
    from the original message, unless the user indicates that they are
    deliberately including previously confidential content in a
    non-confidential message.

Does that seem like a reasonable clarification?

> 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."

In context, this is about the choice for the user's own keys, which are
typically either produced or solicited by the MUA itself.  This does not
talk about warning when the user receives someone else's certificate
that has both purposes enabled.

> 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,

What are those advantages?  I've been asking in LAMPS for quite a while
now for people to speak up about it (see all the discussion that went
into RFC 9216) and gotten no justifications that made sense to me beyond
"some CAs don't know how to do it", which i don't think is a legit
argument.

> 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.

Whose design choice are we talking about here?  If it's just about
dealing with CAs that are making poor choices, those CAs *need* to hear
complaints from customers, and customers need to know that the CAs are
misbehaving.  MUAs can (and SHOULD, as the text says) nudge those
customers to make these complaints.  How else can implementers move the
ecosystem to better cryptographic hygiene?

> 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.

Hm, i agree with you about the value of the use case (maybe HRDAG is an
even better example than Amnesty -- https://hrdag.org/).

We had a similar discussion about whether we should require the MUA to
generate any certificates at all for the user who just wants to send a
quick encrypted e-mail to, say, report a bug in a privacy-focused OS
like Tails
(https://tails.net/about/contact/index.en.html#tails-support-private).
Of course, an encrypted bug report sent by someone without keys of their
own can never receive effective followup with the same cryptographic
protections, if the team handling the bug report can't encrypt their
reply.

But these are unusual enough use cases that we couldn't figure out to
ask a MUA to support them in a usable way without making a pretty
annoying footgun for normal users where sometimes they accidentally
can't read their sent mail just because they wondered "what does this
setting do?"

Consider also that if the recipient of such a message is unaware that
the sender feels themselves to be in the "Amnesty use case", the
recipient might very well reply encrypted, with quoted and attributed
text encrypted to the sender's certificate.  That could again allow for
compelled decryption.  And, if metadata shows that account to have
communicated with Amnesty International, that could put the user of the
account at risk, too.  Especially if retaining the sent message, or even
retaining access to the sending e-mail account ends up pointing the
finger back to the user.

So maybe a better way to support the "Amnesty use case" (or the
deliberately one-off, no-reply Tails bug report use case) is an
ephemeral MUA user profile, which destroys its secret key material (and
sentmail folder and account configuration) when it is released.  This
would leave no metadata traces, and would make compelled decryption by
the user impossible, even if the message was captured by the adversary,
or a reply with quoted and attributed text was mistakenly sent back to
the mail account by the original recipient.  Such an ephemeral profile
can use the guidance that already exists in this document, without
introducing any sort of footgun for normal use.

I'm not sure this document needs to describe that ephemeral MUA user
profiles, though.  Guidance for handling the "Amnesty use case" might be
better off in a dedicated document.

> 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).

These two concerns are flip sides of the same coin.  Indefinite
detention of long-term decryption keys is actually a weakness of e2ee
e-mail today, because it is impossible to actually delete a message in
an unrecoverable way as long as those keys are maintained.  (see the
"Future Work" subsection about "Secure Deletion")

So we need an ecosystem that permits destruction of decryption-capable
keys at some point if we want to be able to achieve the (reasonable)
goal of Secure Deletion.  But we want to reach that goal without making
some messages that users *don't* want to be deleted unreadable, because
every unreadable message encountered by a user is a nudge to push them
away from using e2ee e-mail at all.  (worse, a newly delivered
unreadable message can normalize the antipattern where the recipient
sends a cleartext, unsigned message to the original sender saying
"something didn't work, can you resend in the clear", which opens up a
very wide attack surface for an adversary to exploit)

To achieve the two goals of secure deletion and avoiding unreadable
messages in tandem, we need (a) receiving MUAs to be able to retain
access to desired messages after deletion of the secret key, and (b)
sending MUAs to not encrypt to expired or revoked certificates.

(a) can achieved unilaterally by a user who adopts only MUAs that stash
the session key of each retained message (as described in the third
bullet in the "Reading Sent Messages" subsection).  But (b) can only be
achieved by compliance from the senders MUA, which is why this
recommendation is there.

If we want the ecosystem toward feature and security parity with some of
the siloed, proprietary messaging apps, we need the cryptographically
capable MUAs to pull together here, even if it like "making life more
difficult".

Note that the guidance in "Local Certificate Maintenance" explicitly
recommends checking if the user's own certificates are due to expire,
and refreshing them as appropriate (or warning the user at the very
least).

> 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.

This last sentence of yours got a little garbled, but i think it's meant
to end with "…ask whether to drop those users or to send the message
unencrypted".  The first of those ("drop those users") is approach 2.
The second of those ("send the message unencrypted") is approach 3.

So maybe you do agree with the guidance here? :)

> 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.

These two concerns are also two sides of the same coin.

I agree with you that external subresources are prevalent in mail today.

But we also want the mail indicators to have some readily understandable
semantics that are not fraudulent.  "Only the sender and the recipients
know what this message says" is about as close as we're going to get for
the semantics of an encrypted message.  But if a message contains an
external subresource that simply isn't true, and a MUA with rigorous,
accountable security indicators won't mark it that way.

And giving the sending user an option to do something that will break
the expected indicators at the receiving side depending on whether the
receiving MUA is rigorous seems counterproductive.  This document is
aimed at best practices to foster a usable e2ee mail ecosystem, and
allowing wiggle room here on either side looks like a recipe for
interoperability failures.

I hope this offers some insight as to why these sometimes challenging
recommendations are in the document.  If this discussion brings up any
ideas for concrete improvements in the document, please don't hesitate
to send them along, either by mail, or by issues or merge requests at
https://gitlab.com/dkg/e2e-mail-guidance/

Regards,

        --dkg