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

[Paul Kyzivat <[e-mail]>]

Daniel,

Thanks for the explanation. This all sounds good to me.

But I do encourage you to say *something* about web server based email 
clients, since they are such a big part of the ecosystem.  (What 
percentage of all emails have gmail on at least one end?) Perhaps 
discuss the limitations on secure email with such clients.

	Thanks,
	Paul

On 2/22/24 3:00 PM, Daniel Kahn Gillmor wrote:
> 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