[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.112.185.101 with SMTP id fb5mr51380838lbc.12.1420481327340; Mon, 05 Jan 2015 10:08:47 -0800 (PST)
Received: by 10.25.17.196 with HTTP; Mon, 5 Jan 2015 10:08:47 -0800 (PST)
Date: Mon, 05 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 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.
- [secdir] SECDIR Review of Draft-nottingham-safe-h… Matthew Lepinski