[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, 4 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?