Re: [websec] Issue 54 - Adding a report-only mode

[Tom Ritter]

On 4 March 2013 20:09, Ryan Sleevi  wrote:
> 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?

Obviously I wasn't in Atlanta, but I feel if you're sending the known
pins in the report (and you should) you should send the whole policy
as you know it, including directives, and some mechanism for max-age
that says 'when I think this will expire'.  Maybe even 'when I got
this directive' (if available) and 'where i got this directive from'
(preloaded vs header).

port should be an integer or a string, but one or the other. Why have
it be ambiguous?

-tom
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] Issue 54 - Adding a report-only mode

[Ryan Sleevi]

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 mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec