On Thu, October 18, 2012 5:17 pm, Chris Palmer wrote:
On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker
trac+web...@trac.tools.ietf.org wrote:
#54: Specify a report-only mode
Should there be a report-only mode, allowing site operators to see
how
using HPKP would affect their site's operation in browsers supporting
HPKP? (Probably.)
If so, specify how that mode would work.
What are people's thoughts on this? The motivation for a report-only
mode is twofold: (1) site operators want to see what would happen
before going live with pinning; and (2) site operators often don't
know all their keys, or all their intermediate signers' keys, or all
their trust anchors' keys, and a reporting mode could help them find
out.
(2) implies that the reporting interface would have to allow the UA to
tell the site not just pin validation succeeded/failed, but also why
(probably by simply reporting the entire validated certificate chain
that the UA computed/observed).
The reporting interface must be one that is easy for site operators to
implement â writing code to collect the reports should not be a huge
burden for developers. Perhaps a simple JSON blob:
{
pin-validation-succeeded: (true|false),
expected-pins: [ sha1/blahblah, sha256/foobar, ... ],
validated-chain: [ PEM blob of EE, PEM blob of intermediate,
..., PEM blob of anchor ]
}
The next issue is, should the site be able to specify a URL to which
the UA will POST the JSON blob, or should we specify a single,
well-known URL path? Using a well-known path seems simpler and less
error-prone generally.
To wit, this was also brought up by several people during the IETF 84
presentation.
As an example of how such behaviour might be specified, a similar
report-only mode is implemented with Content Security Policy [1]. In CSP,
both the Content-Security-Policy and the
Content-Security-Policy-Report-Only headers may be present, both are
considered, and both may contain independent/conflicting policies.
In CSP, one of the token/directives is report-uri, which indicates the
URI to use to send violation reports to, as well as a defined format for
what the contents of the report should contain.
The distinction here between PKP and CSP is that CSP is evaluated
per-resource load within a web origin, whereas PKP is enforced at the
transport layer. A PKP violation is nominally detected during the TLS
handshake, and depending on client implementation, may either be treated
as an error during the TLS handshake or immediately following it, prior to
using the connection to transmit the (original) HTTPS request.
If a report-only mode is supported, the following considerations should be
worked out:
- Should the origin of the report URI be constrained the the origin of
the target URI?
- Should the report URI be allowed to specify HTTPS?
- If the report URI specifies HTTPS, and the report URI origin is the
same as the target URI, but the report URI violates either the PKP or
PKP-Report-Only policy, should the report still be submitted?
- Is there a blacklist or whitelist of headers that should be used to
prevent against abuse or compromise. For example, presumably including
cookies in the report submission for an invalid PKP over the same
connection that generated the invalid PKP would be bad, as it may
(will) lead to the compromise of the users' data.
- If the report contains validated certificates, what should the format
be? draft-josepfsson-pkix-textual [3] may be of normative use here.
[1]
http://www.w3.org/TR/CSP/#content-security-policy-report-only-header-field
, with the expired, less-comprehensive draft submitted to IETF at
http://tools.ietf.org/html/draft-gondrom-websec-csp-header-00#section-4.2
[2] http://www.w3.org/TR/CSP/#report-uri
[3] http://tools.ietf.org/html/draft-josefsson-pkix-textual
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
