Re: [lamps] Martin Duke's Yes on draft-ietf-lamps-e2e-mail-guidance-15: (with COMMENT)

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

Hi Martin--

Thanks for your review of draft-ietf-lamps-e2e-mail-guidance.

On Tue 2024-03-05 13:11:59 -0800, Martin Duke via Datatracker wrote:
> Would it be worthwhile to discuss the handling of encrypted email with obsolete
> ciphers, as is done in (6.4) for signatures?

This is a great point, since the document deals with store-and-forward
systems and historical/legacy data, some of which is likely to contain
this kind of stale mechanic.  I'm tracking this as:

   https://gitlab.com/dkg/e2e-mail-guidance/-/issues/17

I've also proposed a new subsection, next to the "signature failures"
subsection, to address this concern in a similar way to the way the
draft already handles "Errant Encryption Layers":

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

The proposed text reads:

------
## Weak Encryption

Sometimes, a MUA might encounter a message with a well-formed Cryptographic Envelope that uses a form of encryption with substantial known flaws.
For example, a PGP/MIME message might use a Symmetrically Encrypted Data packet, which is known to have malleable ciphertext (see {{Section 5.7 of I-D.ietf-openpgp-crypto-refresh-13}}).
ِAs another example, an S/MIME message may use an `enveloped-data` MIME part with a `contentEncryptionAlgorithm` of `rc2-cbc` with `rc2ParameterVersion` of 160, meaning a 40-bit key (see {{Section 5.2 of ?RFC3370}}), which is widely considered breakable via brute force with moderate hardware investment in 2024.
As cryptanalysis and hardware capacities advance, an implementation may widen the scope of what encryption mechanisms are considered weak.

A receiving MUA MUST warn the user that such a message has a known weakness.
The receiving MUA MAY decline to decrypt such a message at all.
If it decides to decrypt a message with a weak encryption layer, it MUST NOT indicate in the message's Cryptographic Summary that the message was encrypted, as the confidentiality of the message is suspect.
This is similar to the approach taken in {{errant-encryption-layer}} for messages with an Errant Encryption Layer.

Like the Errant Encryption Layer situation, there is an asymmetry between rendering and replying to a message with weak encryption.
The guidance in {{reply-to-errant-encryption}} should be followed when replyingn to a message with weak encryption as well.

A receiving MUA MAY also treat historically archived messages with weak encryption differently from modern messages.
For example, if an encryption algorithm was known to be weak in 2005, then a message that appears to have been encrypted with that algorithm in 1995 might decrypted with a warning, as an archival service.
But a message that appears to have been encrypted with that same weak algorithm in 2015 might be quarantined as a likely attack.

There are several possible ways to distinguish a historical message from a modern one, including:

- The message timestamp (e.g., the `Date` header field)
- The time the message was first observed on the network (e.g., delivery of a new message via IMAP from a mailbox that had recently checked)
- The timestamp in any signature observed in the message
- The message structure (a message composed using protocol elements that were invented after the encryption algorithm was known weak is likely to be an attack than a legitimate archival message)
-----


If this proposed text is too controversial to accept, and we can't
manage to arrive at non-controversial guidance, i'd be happy to consider
a short note in the Future Work appendix to flag this as something to be
considered later.

Regards,

        --dkg