Skip to main content

Last Call Review of draft-ietf-appsawg-rrvs-header-field-07
review-ietf-appsawg-rrvs-header-field-07-secdir-lc-cooley-2014-03-17-00

Request Review of draft-ietf-appsawg-rrvs-header-field
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-03-17
Requested 2014-03-13
Authors William Mills , Murray Kucherawy
I-D last updated 2014-03-17
Completed reviews Genart Last Call review of -07 by Vijay K. Gurbani (diff)
Secdir Last Call review of -07 by Shaun Cooley (diff)
Opsdir Last Call review of -07 by David L. Black (diff)
Assignment Reviewer Shaun Cooley
State Completed
Request Last Call review on draft-ietf-appsawg-rrvs-header-field by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 11)
Result Has nits
Completed 2014-03-17
review-ietf-appsawg-rrvs-header-field-07-secdir-lc-cooley-2014-03-17-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 defines an extension for SMTP called RRVS, along with a new MAIL
header field called Require-Recipient-Valid-Since, that allows senders to
indicate to receivers the last date when the sender confirmed the ownership of
the target mailbox with the intended recipient, with a goal of preventing
sensitive mail from being delivered to the wrong party if the ownership of a
mailbox has changed.

The document is easy to understand and covers several information disclosure
issues that might arise from abuse of the RRVS extension or matching header.  I
consider this document to be ready for publication with two small nits:

 - The suggested abuse countermeasures described in 14.1 should be reworded to
 indicate that operators SHOULD (or are RECOMMENDED to) implement
 countermeasures against RRVS probing.

 - The suggested use restrictions described in 14.2 should be reworded to
 indicate that operators SHOULD (or are RECOMMENDED to) accept any RRVS
 datetime as valid for accounts that have only had a single owner, even if the
 RRVS datetime predates the creation of the target account.

-Shaun