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
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
