Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lamps-e2e-mail-guidance-14

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

Hi Paul--

Thanks for this review!  I've just staged some minor cleanup edits in
git (https://gitlab.com/dkg/e2e-mail-guidance/) that should address your
concerns.  After my co-editors have had a chance to review and discuss,
we'll probably roll them up with the suggestions from other reviewers
into a new draft.

More comments interleaved below:

On Sat 2024-02-17 18:31:18 -0500, Paul Kyzivat wrote:
> 1) NIT: Section 9.7.2:
>
> In the following:
>
> "If such a proxy handles certificate discovery in inbound messages (see 
> Appendix A.2.1), it will also need to communicate the results of that 
> discovery process to its corresponding proxy for message composition 
> (see Section 9.7.1)."
>
> I think there is a problem here with "... proxy ... communicate ... to 
> ... proxy". Shouldn't it communicate to the MUA?

In the transparent proxy scenario (which this section is warning about),
the proxy doesn't/can't communicate to the MUA about cryptographic
information, because the MUA is decidedly ignorant.  So the text here is
as intended -- it's about the inbound proxy talking to the outbound
proxy.  But i agree it could be clearer, the first proxy is now "inbound
proxy" and the second proxy is now "outbound proxy".

> 2) NIT: Section 2.2
>
> s/Implmenters/Implementers/

thanks, fixed.

> 3) NIT: Section 8.1.1
>
> s/rFC822Name/RFC822Name/

I think this should actually be rfc822Name (this is how it appears in
e.g., RFC 8705).  I'll fix both instances of the term.

> 4) NIT: Section 9.5
>
> s/(e.g. and IMAP mailbox)/(e.g. an IMAP mailbox)/

thanks, fixed.

> 5) NIT: IdNits:
>
> IdNits reports many things, most of them bogus. A couple of them look to 
> me like they deserve consideration:
>
>    -- Obsolete informational reference (is this intentional?): RFC 3501
>       (Obsoleted by RFC 9051)

good catch, updated.

>    -- Duplicate reference: draft-ietf-openpgp-crypto-refresh,
>       mentioned in 'I-D.ietf-openpgp-crypto-refresh', was also
>       mentioned in 'I-D.ietf-openpgp-crypto-refresh-13'.

Thanks, fixed by pointing to draft -13 uniformly.


> Other Comments/Questions:
>
> I found this document very informative. I wasn't aware how many issues 
> there are with this feature. The work required to make an MUA comply 
> with this document seems daunting. Is it expected that this will happen 
> for popular MUAs?

I agree that it is daunting.  My takeaway from working as an editor on
this document is that no one has really tried to make an e-mail client
that is natively secure and easy to use from an end-to-end cryptographic
perspective before.  In fact, in some of the testing i've done, i'm
reminded of the state of web browsers in about 1998, where some folks
had done some thinking about security, but what security mechanisms
existed were pretty haphazard and definitely not robust.

We've done a lot of work on web browsers since then, including work to
explicitly document and standardize what kinds of cryptographic state
are kept, how certain (cryptographic and non-cryptographic) features
interact, and how to mitigate risks from those interactions. Sadly, no
one ever seems to have done that work for MUAs that i've been able to
find.  This document can be read either as a foundation for that kind of
work, or as a wistful epistle from a future that might have been.  I'd
prefer the former, of course, but we'll see.

I don't know of any MUA that actually implements all of these
recommendations yet, though each recommendation is drawn from actual
behaviors of clients in the wild today.

I can't speak to the intent of popular MUA developers, thouh, sadly.

> Also, do you consider web server based implementations of email clients 
> (such as gmail) to be proxies? If so it might be good to say so 
> explicitly. If not, then should they be discussed separately?

Due to the operational model of the web, I think there are some pretty
fundamental challenges to a remotely-hosted webserver-based MUA that
wants to offer end-to-end cryptographic security.

In particular, if you assume that the webserver hosting the MUA itself
is part of the threat model, then there are many many additional
concerns that we did not include in this document.

> When composing a reply a user may find that desired parts of a 
> replied-to message have not been quoted by the MUA. (Due to the rules in 
> 5.4.) Such user is likely to curse and then simply copy/paste the 
> desired text. Is the MUA expected to detect this behavior and discourage it?

My experience is that most users (outside of peculiar types like IETF
participants) have no idea that there is any quoted and attributed text
pasted into their e-mails in the first place.  They simply type where
the cursor is placed ("top-posting"), and carry on, oblivious to
whatever stuff the MUA injected below their cursor.

Such a user will not curse if there is no quoted and attributed text;
they simply won't notice.  The MUAs job is to avoid accidentally leaking
the user's cleartext, not to prevent the user from deliberately leaking
cleartext.

If the user decides to paste sensitive material of any kind into a
cleartext message (e.g., credit card numbers, passwords, or cleartext
copies of other messages) there's really nothing that an MUA can do
about it (though i can imagine some fancier MUAs having a "it looks like
this cleartext e-mail contains a credit card number; are you sure you
want to send it?" feature, the same way that some MUAs capable of simple
sentiment analysis or word selection scoring might say "this e-mail
message looks rather heated; would you like to wait 10 minutes to cool
off and review before sending it?"

But that kind of work is pretty clearly outside the scope of
e2e-mail-guidance :)

I really appreciate the time you took to review the draft!

                  --dkg