Re: [Jmap] Secdir last call review of draft-ietf-jmap-mdn-16

[Barry Leiba <[e-mail]>]

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 <
[e-mail]> 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.
>
>
>