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

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

Hi Roman--

Thanks for this thoughtful and detailed review.

We've addressed the parts that made sense to address directly with
changes in the document, and released a new version of the draft,
draft-ietf-lamps-e2e-mail-guidance-14.

More comments interleaved below, in particular highlighting sections we
didn't feel we could address with changes to the document, which are
called out with [UNCHANGED].

Where i've elided your text, we've adopted changes in the draft that we
feel addressed them.

On Thu 2024-01-18 18:08:03 +0000, Roman Danyliw wrote:

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

This is a good suggestion.  We took this and several of the other
comments together to explicitly call out three categories of MUA.  we've
described them in the terminology section as:

- A *Non-cryptographic* MUA has no capabilities for end-to-end cryptographic protections.
- A *Conformant* MUA follows the guidance in this document when dealing with end-to-end cryptographic protections.
- A *Legacy* MUA has capabilities for end-to-end cryptographic protections, but does not adhere to the the guidance in this document.

This made it much more straightforward to turn many SHOULDs into MUSTs
(for conformant MUAs) and remove some of the equivocations.  Where
SHOULDs remain, we tried to explicitly call out the circumstances
where a reasonable MUA might deviate from the guidance.

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

We tried to clarify here that while four states might be required for
receiving/interpreting messages, three states is probably as much as you
want for composing.

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

[UNCHANGED]

Alas, we don't have a citable UX survey, but we all know that UX/UI
inertia is a real lived experience, for all kinds of tools.  If anyone
can point to a survey, we can certainly point to it.

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

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

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

This section is about considering replacements to e-mail that might have
decent e2e protections.

SMS doesn't have any e2e cryptoraphic protections, so it's not an
eligible replacement if the goal is e2e protections.  SMS also doesn't
allow for significant structured data.  We've called this out more in
the text now.

If there are additional textual changes you'd like us to consider, we're
happy to review.

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

the pool of "legacy" MUAs (as defined in the new categorization) is
definitely overwhelmingly large today, and the pool of non-cryptographic
MUAs is even larger.  We're trying to move the ecosystem out of that.
As the authors, we think it's fair to call those systems by these names.

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

I think the editors of this document all agree with you that the current
landscape for e-mail security UX is *not* the current landscape for
browser/site security UX.  We've tried to make the analogies to https
security indicators more explicit.

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

[UNCHANGED]

We don't know of any specific research advocating for simplicity,
unfortunately.  There are many "johnny can't encrypt" experiments that
show how complex UX fails users. Is there any one in particular that you
think we should cite?

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

Although we clarified this some, i think the only place where a MUA
could know is if it's part of a dedicated deployment.  The future work
section does recommend research work about how to infer or signal
"Expectations of Cryptographic Protection"


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

OK, the use case you're describing is pretty strange for e-mail, since
every e-mail message today has a From: address.  If you have a "From"
address, you're not anonymous, you're pseudonymous at best.  And in
fact, a pseudonymous cryptographic identity is useful for followup.  And
if certificate issuance is straightforward (it is trivial for OpenPGP,
and easy enough for S/MIME if you don't mind a self-signed cert) there's
nothing stopping a sending user who has no intention to follow up from
just generating an ephemeral key to sign with and then throwing it away.

So the use case for encrypted+unsigned is basically: pseudonymous
submission with no interest from the receiving party in confidential
followup discussion.  This is sufficiently rare that MUA developers
probably shouldn't design around it, as it makes the other more common
use cases much harder to think about.  We've adjusted the text to say
the use case is "not common".

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

we're saying that, like the content of a web page can't change the
browser lock icon, the content of an e-mail shouldn't be able to tweak
the UI that shows the cryptographic summary.  We've tried to explain
that a bit more, but if you have more useful text we're happy to
consider it.

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

[UNCHANGED]

We don't see an attack here: if the structure isn't modified, nothing
else will be different here.  and if the structure is modified, then the
handling described here won't permit any spoofing of the modified
message's status.  Do you have a more detailed description of the
problem you're concerned about?

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

[UNCHANGED]

This paragraph is not about the wire format, it's about the UI of the rendering
agent.  Can you think of a way that we should clarify this?

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

We added a brief discussion of this, and then also referred it to the
Future Work section about "Use of Smartcards or Other Portable Secret Key Mechanisms".


> ** 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’/

We changed s/composing/sending/ in this sentence to clarify what we're
talking about.  There is of course also a separate section about Drafts,
specifically.

> ** 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”?

Yes, thanks.  Discussing this, we identified that the document lacked
the explicit guidance that drafts SHOULD be encrypted as long as the
Drafts folder might be readable by an attacker.  We've added that
recommendation.

The editors,

        --dkg (and Alexey and Bernie)