[websec] Issue 54 - Adding a report-only mode
"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Tue, 05 March 2013 01:09 UTC
Return-Path: <ryan-ietfhasmat@sleevi.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F9A11E80D5 for <websec@ietfa.amsl.com>; Mon, 4 Mar 2013 17:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level:
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbCaBsj4b4Go for <websec@ietfa.amsl.com>; Mon, 4 Mar 2013 17:09:37 -0800 (PST)
Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 400D111E80AE for <websec@ietf.org>; Mon, 4 Mar 2013 17:09:36 -0800 (PST)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 0EC271006D for <websec@ietf.org>; Mon, 4 Mar 2013 17:09:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=UXXRMFBfb0YG5U22McCr lgJgoJ4=; b=YulwtiiUkCrrIpQtJBOrjz/KCs2OQ1ev/r34HjwjzfOis5No96yM wweZvDqN9Dc6IItQ8ldzDWFqz7bRX3A23cIgLoA8BK11aknAD0rl8WcOMQGo2LXw bGLYAB5hg5CEE6nFIYiY/+RsTC9yk8FulNOKI2VYbMugRhgce2V6E4E=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 01DCC10062 for <websec@ietf.org>; Mon, 4 Mar 2013 17:09:35 -0800 (PST)
Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 4 Mar 2013 17:09:36 -0800
Message-ID: <0e3af2fc9efa802944efa946a800b62b.squirrel@webmail.dreamhost.com>
Date: Mon, 04 Mar 2013 17:09:36 -0800
From: Ryan Sleevi <ryan-ietfhasmat@sleevi.com>
To: websec@ietf.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [websec] Issue 54 - Adding a report-only mode
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ryan-ietfhasmat@sleevi.com
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2013 01:09:38 -0000
As discussed during Atlanta, and as raised in http://trac.tools.ietf.org/wg/websec/trac/ticket/54 , there's a strong desire for a Content Security Policy-like report and report-only mode. The use of a report mode is not as an attack mitigation, but as a way of sites to be informed of misconfigurations. The use of a report-only mode is as a way to allow sites to experiment with and deploy a Pinning Policy effectively. Given that pinning is effectively ultimately dependent on client trust and PKI policies, it's important for site operators to be able to ensure their proposed pinning policy will work effectively. To that end, draft-04 has introduced the report-uri directive, Section 2.1.3, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.3 , which allows a site to specify a URL to direct reports, as described in Section 3 - http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-3 In addition, and in the spirit of CSP, we'd like to propose the addition of a Public-Key-Pins-Report-Only header, as described in Section 2.1 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1 - as a compliment to the Public-Key-Pins header. This header would follow the same syntax and semantics of the Public-Key-Pins header, with the exception of not actually enforcing the pins (as described Section 2.6). I'd like to solicit feedback and make sure that both the discussions from Atlanta and from the list have been accurately captured. Are there concerns with a Report-Only mode that have not been accurately captured?
- [websec] Issue 54 - Adding a report-only mode Ryan Sleevi
- Re: [websec] Issue 54 - Adding a report-only mode Tom Ritter