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

[Martin Duke <[e-mail]>]

Thanks for considering the comment. I'm fine with the change, though I have
little technical judgment about the specific guidance.

On Wed, Mar 13, 2024, 17:04 Daniel Kahn Gillmor <[e-mail]>
wrote:

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