Daniel, thanks for the review. And yes, MDNs themselves, no matter how they conveyed, are privacy-intrusive. That’s why I have them disabled in my user agent, and most, if not all standards-compliant MUAs allow that.
And that’s not accidental: it actually is written into the MDN spec, RFC 2298. From Section 2.1:
While Internet standards normally do not specify the behavior of user interfaces, it is strongly recommended that the user agent obtain the user's consent before sending an MDN. This consent could be obtained for each message through some sort of prompt or dialog box, or globally through the user's setting of a preference. The user might also indicate globally that MDNs are never to be sent or that a "denied" MDN is always sent in response to a request for an MDN.
There’s more there, as well, and I think it covers things reasonable well, even if it doesn’t explain what the threats are. If we should ever do an update of the MDN spec, we would definitely add that.
Barry, ART AD
On Tue, Jan 5, 2021 at 9:41 PM Daniel Franke via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Daniel Franke
Review result: Ready
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should
treat these comments just like any other last call comments.
This document's Security Considerations section is appropriately brief because
it doesn't introduce much in the way of new ones: the security model for JMAP
MDN isn't essentially different from the security model for the analogous IMAP
functionality. But had I reviewed RFC 8098, I would have urged some changes to
the Privacy Considerations section of that document. It's not that anything is
wrong or overlooked, but its emphasis is odd. It focuses mostly on leakage of
impersonal details like OS version and network topology, with nothing but a
parenthetical mention given to the significant personal intrusion of monitoring
message read times. Every abusive boss knows this trick: send your subordinates
an email at 5:00 AM on Saturday and watch when the delivery receipts come in. I
wish that something in the corpus of MDN-related RFCs would do a better job of
acknowledging this, even if this one in particular is not the most appropriate
place for it.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
