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

Daniel Franke via Datatracker <noreply@ietf.org> Wed, 06 January 2021 02:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E14F3A0418; Tue, 5 Jan 2021 18:41:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Franke via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-jmap-mdn.all@ietf.org, jmap@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160990091746.16663.18138161640943053349@ietfa.amsl.com>
Reply-To: Daniel Franke <dafranke@akamai.com>
Date: Tue, 05 Jan 2021 18:41:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/YlX5hlhl4VeBZRE4W5uNZGwemwE>
Subject: [Jmap] Secdir last call review of draft-ietf-jmap-mdn-16
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2021 02:41:58 -0000

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.