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

[Roman Danyliw <[e-mail]>]

Hi dkg!

Thank you for the prompt and extensive changes in -14, and detailed response below.  Top line, -14 addresses my feedback.  In particular, I find the new taxonomy around MUA types and the guidance tied to the simplified mental model in Section 3.1 to be crisp and well balanced guidance to implementers in an ecosystem of MUA with a variety of capabilities.

As the next step, I've sent the document to IETF LC. 

Thanks,
Roman

> -----Original Message-----
> From: Daniel Kahn Gillmor <[e-mail]>
> Sent: Thursday, February 1, 2024 12:24 PM
> To: Roman Danyliw <[e-mail]>; [e-mail]
> Subject: Re: [lamps] AD Review of draft-ietf-lamps-e2e-mail-guidance-13
> 
> 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)