Last Call Review of draft-nottingham-safe-hint-05
review-nottingham-safe-hint-05-secdir-lc-lepinski-2015-01-08-00

Request Review of draft-nottingham-safe-hint
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-11-18
Requested 2014-10-23
Authors Mark Nottingham
Draft last updated 2015-01-08
Completed reviews Genart Last Call review of -05 by Brian Carpenter (diff)
Genart Telechat review of -05 by Brian Carpenter (diff)
Secdir Last Call review of -05 by Matt Lepinski (diff)
Assignment Reviewer Matt Lepinski 
State Completed
Review review-nottingham-safe-hint-05-secdir-lc-lepinski-2015-01-08
Reviewed rev. 05 (document currently at 11)
Review result Ready
Review completed: 2015-01-08

Review
review-nottingham-safe-hint-05-secdir-lc-lepinski-2015-01-08

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 with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Some websites have both a standard version and also a "safe" version with "objectionable" content removed. This document specifies a mechanism for an HTTP client to request that -- in such a case -- the server provide the "safe" version. This document makes no attempt to define a "safe" website or to define "objectionable" content. It merely provides a way for the client to let the server know that a "safer" version is desired if multiple versions are available.

This document is generally in good shape and I believe it is ready for publication.

This mechanism is not intended to provide any security properties and the authors are clear in the security considerations with regards to security properties that are out of scope for this mechanism. 

However, the authors should consider making the following explicit in the security considerations section. In the case where an intermediary/man-in-the-middle changes the Prefer header (perhaps maliciously), it is not possible for the intermediary to produce a worse experience than would exist without this mechanism. That is, the mechanism only provides a way to request a safer-than-usual version of the website, therefore if the Prefer header is modified the worst that can happen is that the user is provided the "usual" version of the site -- the version that they would receive today without this mechanism.