Skip to main content

Last Call Review of draft-ietf-jmap-mdn-16
review-ietf-jmap-mdn-16-secdir-lc-franke-2021-01-05-00

Request Review of draft-ietf-jmap-mdn
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-09-18
Requested 2020-09-04
Authors Raphaël Ouazana
I-D last updated 2021-01-05
Completed reviews Secdir Last Call review of -16 by Daniel Fox Franke (diff)
Genart Last Call review of -15 by Joel M. Halpern (diff)
Assignment Reviewer Daniel Fox Franke
State Completed
Request Last Call review on draft-ietf-jmap-mdn by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/MGO-bOGhOWDxTNW-XfZOm7lBk-s
Reviewed revision 16 (document currently at 17)
Result Ready
Completed 2021-01-05
review-ietf-jmap-mdn-16-secdir-lc-franke-2021-01-05-00
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.