[secdir] SECDIR Review of Draft-nottingham-safe-hint

Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 05 January 2015 18:08 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D61A8724; Mon, 5 Jan 2015 10:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id naOzIWEEmrE1; Mon, 5 Jan 2015 10:08:49 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8DB1A0371; Mon, 5 Jan 2015 10:08:49 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id f15so20088024lbj.23; Mon, 05 Jan 2015 10:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9jAT1ocOnjXpWMsaCN8ACAXCTmsQy6Ev0ghCWFt5v6A=; b=r6rr/DAAsjQ3D9/Jvp1zEZQUrD3xaHPCwW22Spz9w4DiRJCe7vkMufxghFpdwOtHJn OSAnFbxIsgv28DOVi0b7Ztbplm/apMAUn3kbbrQMjj35F12cxAAZdNRBQhUOcNGV9WBO T1SpJJHvQL+J/O7sHoZoW240FP7aGB1zMn1SXYn6B0DbVy9j7v0D6YnGIYKXxLsjUaC2 vz+6ZRdIaa2BtKRTUQwvBZBXeJ+iJqC/1MjISFJxXyzuIGl80ql8pEeIItWlj/S0Yxnb FIvOd0UnXANbhpLNmMXrQ8YyDiWRvaZdcexafsm8fJ746GCPd5OeVUf6p4Lw+Y5wTR/7 cDBw==
MIME-Version: 1.0
X-Received: by with SMTP id fb5mr51380838lbc.12.1420481327340; Mon, 05 Jan 2015 10:08:47 -0800 (PST)
Received: by with HTTP; Mon, 5 Jan 2015 10:08:47 -0800 (PST)
Date: Mon, 5 Jan 2015 13:08:47 -0500
Message-ID: <CANTg3aAtDTWGe88z=iraGctbay7dwqViEOdDig0yc6Q63yz5wg@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-nottingham-safe-hint.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a11c3c516ed2143050beb94aa
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/JVk5rGUHkat7-cOREHuFLV5aoVs
Subject: [secdir] SECDIR Review of Draft-nottingham-safe-hint
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jan 2015 18:08:56 -0000

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

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.