[lamps] AD Review of draft-ietf-lamps-e2e-mail-guidance-13

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-lamps-e2e-mail-guidance-13.  Thanks for the significant work on this document, and attempting to improve the real-world uptake and usability of E2E mail.  My feedback is below.

** What are the WG expectations for implementors on applying the design guidance and associated configuration?  The abstract reminds us that the associate standards for cryptographic protection provide “extremely flexibility.”  I don’t quarrel with that assessment.  I observe that there is a large number of SHOULDs in this document, many without explanation on why the prescribed behavior is not mandatory.  This seems exactly akin to the flexibility that motivated this document.  Several examples include:

-- Section 4.5:  “An Errant Cryptographic Layer SHOULD NOT contribute to the message's overall cryptographic state.”

-- Section 5.2. “A MUA SHOULD NOT generate an encrypted and signed message where the only signature is outside the encryption.”

-- Section 6.1. “The Cryptographic Layers themselves SHOULD NOT be rendered otherwise.”

-- Section 6.2.2.1.  “When composing a reply to a message that has any encryption layer, even an errant one, the reply message SHOULD be marked for   encryption, as noted in Section 5.4.”

-- Section 7.2. “For a message with end-to-end cryptographic protection, any attachment SHOULD be included within the Cryptographic Payload.  If an attachment is found outside the Cryptographic Payload, then the message is not well-formed (see Section 6.1), and will not be handled by other MUAs as intended.”

-- Section 8.2.1.1.  “The MUA SHOULD NOT encourage the use of a single S/MIME certificate for both encryption and signing, to avoid possible cross-protocol key misuse.”  How would the MUA know it is acceptable for cross-protocol key reuse to happen?

For all the above, I would ask, why aren’t these a “MUST”?  Under what circumstances would this behavior be acceptable?  

Did the working group consider making this a “profile” of sorts where all of these proposed practices were mandatory?

Additionally, the document, especially in Section 3.* makes reference to “legacy” ecosystems and tools.  It isn’t clear to me what that ecosystem entails?  How does one know an implementation is “not legacy”?  Is it implementations that follow this document? With the preponderance of “SHOULDs” in this document, I’m having trouble understanding what conformance to this document would even mean.

** Section 3.1 presents a compelling framework.  A few questions on it:

-- The assertion in this section is that “even ... four states approach the limits of complexity for an interface for normal users”.  Why is there confidence that the three states of “unprotected, verified and confidential” can be handled by the user?  Why does one state less make a difference?  Could an argument be made that it should be just two (unprotected or signed+encrypted)?

-- How is this mental model supposed to be used by implementers?  There are a number of places later in the document where it seems like it could be invoked but is not.  For example:

oo Section 6.2.1.  “In such a situation, an MUA SHOULD NOT indicate in the Cryptographic Summary that the message is signed.”  Should this be shown as “unprotected.” How would a user troubleshoot the error if it is being hidden from them? 

oo Section 6.2.1.1.  “Then, the MUA MAY indicate to the user that this is a signed message that has been wrapped by the mailing list.”  In the Section 3.1 mental model, does this mean it is “signed”?  

oo Section 6.2.3.1.  “It is challenging to communicate to the user exactly which part of such a message is covered by the signature, so it is better to leave the message marked as unsigned”

oo Section 6.4. “A MUA SHOULD NOT render a message with a failed signature as more dangerous or more dubious than a comparable message without any    signature at all.”

oo Section 9.9.  “A receiving MUA that encounters a message with end-to-end cryptographic protections that contain a subresource should either refuse to retrieve and render the external subresource, or it should decline to treat the message as having cryptographic protections.”


More detailed feedback follows:

** Section 1.1.2.  Editorial.  Define user headers just like structural headers. 

OLD
   Of all the headers that an e-mail message may contain, only a handful
   are typically presented directly to the user.  Typically, user-facing
   headers are:

NEW (rough)
   Of all the mail header fields headers that an e-mail message may contain, only a handful
   are typically presented directly to the user.  This document refers to them as “user-facing” headers.  Typically, these are:

** Section 2.2.  Per the section header of “E-mail Users Want a Familiar Experience”, what is the basis of that assertion regarding the users' desires?  Is there a citable UX survey?

** Section 2.2.
   *  Ubiquity: Most correspondents will have an e-mail address, while
      not everyone is present on every alternate messaging service,

What is the basis of this assertion?  With mobile device penetration rate reaching billions, is there citable confidence that more people have/use email vs. have/use SMS?  Perhaps there is a distinction being made that SMS is not “internet”?

** Section 2.2
   *  Federation: interaction between users on distinct domains who have
      not agreed on a common communications provider is still possible,
      and

See above.  Isn’t that true of SMS too?

** Section 2.2
   A user of e-mail is likely using e-mail instead of other systems
   because of the distinctions outlined above.  

What is the basis of this assertion? Isn’t some email usage driven by community factors.  For example, I might prefer to use GitHub Issues or Slack/Zulip/etc for IETF communication on drafts but our processes require email in certain cases.  As another example, my employer forces me to use email for certain internal workflow.  In the enterprise setting, my MUA of Outlook is chose for me.

** Section 2.2.  Typo. s/Implmenters/Implementers/

** Section 2.2
   Care should be taken that enabling
   cryptography in a MUA does not inadvertently limit the ability of the
   user to interact with legacy correspondents.

Is “legacy correspondents” someone who doesn’t support encrypted email?  If so, that’s an odd phrasing to me since I would assert that encrypted email is a small fraction of all email.  The dominant way to send email is without S/MIME or OPENPGP cryptography.

** Section 2.3
   By analogy, when the user of a MUA first enables end-to-end
   cryptographic protection, it's likely that they will want to see
   which messages _have_ protection.  But a user whose private e-mail
   communications with a given correspondent, or within a given domain
   are known to be entirely end-to-end protected might instead want to
   know which messages do _not_ have the expected protections.

This analogy to the https lock doesn’t seem exactly right and suggests complexity.  There is strong analog to the “browser-lock-icon” but it seems weak with the current “browser-declares-everything-but-HTTPS-insecure.”  I assert that most email is not E2E encrypted so now the user needs to remember if communication with a given party should be encrypted to call out if it has failed.  Additionally, the transition to HTTPS largely happened transparently for the end user – the migration was done by the website operators and browsers implementors spurred by the availability of free TLS certificates.  Put in another way, the end user didn’t have to do anything.  With encrypted email, the end user is in the loop having to do something different. 

** Section 3.1
   However, most users do not have (or want to have) a sophisticated
   mental model of what kinds of protections can be associated with a
   given message.  Even the four states above approach the limits of
   complexity for an interface for normal users.

My intuition agrees with that, but is there citable research or references to this effect?

** Section 3.1
   In an ecosystem where encrypted-only messages are never deliberately
   sent (see Section 5.3), representing an Encrypted But Unverified
   message as a type of user-visible error is not unreasonable.

How does one know they are in such an ecosystem?

** Section 3.1
   Note that a cleartext message with an invalid signature SHOULD NOT be
   represented to the user as anything other than Unprotected (see
   Section 6.4).

I’m reading “cleartext message” as no encryption with an invalid signature.  Why is this not a MUST?  Under what circumstances would be it appropriate to return back “Verified” or one of the Encrypted states (Confidential or Encrypted but not verified)?

** Section 3.1
   In a messy legacy ecosystem, a MUA may prefer instead to represent
   "Signed" and "Encrypted" as orthogonal states of any given message,
   at the cost of an increase in the complexity of the user's mental
   model.


-- For example, MS Outlook does this now.  The presentation for encrypted is orthogonal to signed.  What is the basis to say this complexity is significant?  

-- Editorial.  Why the judgement of “messy legacy ecosystem”?

** Section 4.1.*.  Should all references to RFC4880 be replaced by draft-ietf-openpgp-crypto-refresh-13?

** Section 5.2.  Editorial.
   Users expect any message that is both signed and encrypted to be
   signed _inside_ the encryption, and not the other way around.

Do users expect it or is it a matter of best practice?  Section 2 spends some time talking about how users don’t understand the details.

** Section 5.3. Typo. s/be be/be/

** Section 5.3.
   It is unclear what the use case is for an e-mail message with end-to-
   end confidentiality but without authenticity or integrity.

Consider the use cases of an anonymous submission.  Recipient publishes a key.  Sender uses a throw away or anonymous account to confidentially send content without signing it.

** Section 6.1
   The receiving MUA should evaluate and assemble the cryptographic
   properties of the Cryptographic Envelope into a Cryptographic Summary
   and display that status to the user in a secure, strictly-controlled
   part of the UI.  In particular, the part of the UI used to render the
   Cryptographic Summary of the message MUST NOT be spoofable,
   modifiable, or otherwise controllable by the received message itself.

-- What is a “strictly-controlled part of the UI”?

-- Isn’t the Crypto Summary derived from the received message?  If so, isn’t it influencing the value of the Crypto Summary.  Hence, I’m not sure what “not modifiable” or “not controllable” might mean.

** Section 6.2.1.1.  Does the guidance in Section 6.1 of the cryptography summary not being able to spoofable apply.  Can an attacker change behavior, perhaps by injecting a List-ID header?

** Section 6.3

   The rendering MUA MAY render a Cryptographic Summary of the
   protections afforded to the forwarded message by its own
   Cryptographic Envelope, as long as that rendering is unambiguously
   tied to the forwarded message itself, and cannot be spoofed either by
   the enclosing message or by the forwarded message.

Does “unambiguously tied” mean well formed headers and message boundaries?

**  Section 6.4
   A MUA that encounters an encrypted-and-signed message where the
   signature is invalid SHOULD treat the message the same way that it
   would treat a message that is encryption-only.

Won’t this inconsistent treatment of a message (i.e., some MUA might treat this SHOULD as a MUST, others might as RECOMMENDED or MAY) lead to confusing behavior in the MUAs from the perspective of the user?

** Section 6.4
   Some different ways that a signature may be invalid on a given
   message:

..

   *  the signature relies on suspect cryptographic primitives (e.g.
      over a legacy digest algorithm, or was made by a weak key, e.g.,
      1024-bit RSA)

Is this invalid in the sense of policy?  The signature might technically validate from the “math perspective” but policy says there shouldn’t be confidence in that signature?  If is so, it might be helpful to clarify this matter.

** Section 7.1

   Note that due to uncertainty about the capabilities and configuration
   of the receiving MUA, the composing MUA SHOULD consider that multiple
   parts might be rendered as the Main Body Part when the message is
   ultimately viewed.

It wasn’t clear to me from this text or the subsequent paragraph what an implementer should do after considering that multiple parts might be rendered into the main body part.

** Section 7.3.  Typo. s/folloiwing/following/

** Section 8.2.1

   If the MUA does not have any certificate or secret key for the user,
   it SHOULD help the user to generate, acquire, or import them with a
   minimum of difficulty.

Recommend using a lower-case SHOULD here if what constitutes “minimal difficulty” can’t be qualified.

** Section 8.2.1.1   
   A better approach is for the MUA to integrate some form of automated
   certificate issuance procedure, for example, by using the ACME
   protocol for end user S/MIME certificates ([RFC8823]).

In addition to ACME, wouldn’t a hard token of some kind with the certificates also be useful?

** Section 8.2.1.3
   Regardless of protocol used (S/MIME or PGP), when producing
   certificates for the end user, the MUA SHOULD ensure that it has
   generated secret key material locally, and MUST NOT accept secret key
   material from an untrusted external party as the basis for the user's
   certificate.

This is good advice.  This document repeatably suggests that the end user is unlikely to know the cryptographic details (and secure defaults are needed).  This technically nuanced guidance might be difficult to attain for the class of user previously scoped.

-- How will the MUA know what is a “trusted vs. untrusted external party” when presented with a secret key material?

-- Related is under what circumstance it is acceptable NOT to generate the secret key material locally?

** Section 8.2.2.

   *  The user's own certificate set for the account does not include a
      valid, unexpired encryption-capable X.509 certificate, and a
      valid, unexpired signature-capable X.509 certificate.

Is this advice relevant in OpenPGP-only deployments?

** Section 9.1

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

During composition, isn’t it more common to be stored in a “Drafts” folder (e.g., Outlook, RoundCube).  Only after it has been sent might it go into ‘Sent’/

** Section 9.5
   When composing a message, most MUAs offer the opportunity to save a
   copy of the as-yet-unsent message to a "Drafts" folder.  If that
   folder is itself stored somewhere not under the user's control (e.g.
   and IMAP mailbox), it would be a mistake to store the draft message
   in the clear, because its contents could leak.

-- Don’t many mail clients “auto-save” into the Drafts rather than asking for explicit tasking to save the draft (e.g., Outlook, Gmail)?

-- Isn’t it a default config on many MUAs to auto-save to drafts?  Should guidance be given about?

** Section 9.5

  Furthermore, when encrypting a draft message, the message SHOULD only
   be encrypted to the user's own certificate, or to some equivalent
   secret key that only the user possesses.

Does this assume that the encryption/signing operation doesn’t just happen when the “Send button is pressed”?

** Section 9.7.2.  Typo. s/negogiate/negotiate/

** Section 9.8.  Typo. s/the the/the/

** Section 9.9.
   A receiving MUA that encounters a message with end-to-end
   cryptographic protections that contain a subresource should either
   refuse to retrieve and render the external subresource, or it should
   decline to treat the message as having cryptographic protections.

Is uppercased MUST or SHOULD appropriate here?

Thanks,
Roman