Re: [websec] #54: Specify a report-only mode

[websec issue tracker]

#54: Specify a report-only mode

Changes (by pal...@google.com):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Draft -08 specifies a report-uri directive and a JSON format to be POSTed
 to the given URI.

-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  closed
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:  fixed
 Keywords: |
---+

Ticket URL: 
websec 

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

Re: [websec] #54: Specify a report-only mode

[Chris Palmer]

On Fri, Oct 19, 2012 at 8:56 AM, Tom Ritter  wrote:

> It hurts me to say so, because it's going to be more work and
> complication and delay - but I agree a reporting system should be
> added.

:)

>>>  {
>>>"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" ]
>>>  }
>
> I like this, although I would include the entire PKP header, the Host
> header, and request URI.

OK.

>>   - Should the origin of the report URI be constrained the the origin of
>> the target URI?
>
> No, you should be allowed to specify a third party domain.  I could
> easily see a third party service collecting these reports as a free or
> paid service.  Google Webmaster Tools may even grow into collecting it
> and CSP violations.

I think we should follow precedent, i.e. CSP, and allow aribtrary
report URIs. This too hurts me to say. :) But consistency with
existing specifications and implementations is preferable to inventing
a new behavior for a similar feature.

>>   - Should the report URI be allowed to specify HTTPS?
>
> Yes.  This is potentially sensitive information, and we would like it
> to be protected in transit.

Agreed.

>>   - 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?
>
> Honestly I don't see why not.  If it is an attacker, the attacker will
> know the user rejected the TLS connection, and will have a good idea
> it was because of pinning.  So what's the harm in telling them the
> additional information.  Vs if it is a legit screw-up by the site,
> they would still like to have the information.

Agreed.

>> - 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.
>
> I don't think any headers other than the PKP, Host, and URL would be needed.

So, whitelist. That is good.

>>   - If the report contains validated certificates, what should the format
>> be? draft-josepfsson-pkix-textual [3] may be of normative use here.
>
> I have no opinion.

draft-josepfsson-pkix-textual works fine for me.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #54: Specify a report-only mode

[Ryan Sleevi]

On Fri, October 19, 2012 8:56 am, Tom Ritter wrote:

> >   - Should the report URI be allowed to specify HTTPS?
>
>  Yes.  This is potentially sensitive information, and we would like it
>  to be protected in transit.
>
> >   - 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?
>
>  Honestly I don't see why not.  If it is an attacker, the attacker will
>  know the user rejected the TLS connection, and will have a good idea
>  it was because of pinning.  So what's the harm in telling them the
>  additional information.  Vs if it is a legit screw-up by the site,
>  they would still like to have the information.
>


I should have mentioned the other scenario that is closely related, which
is that independent of whether the report URI is different than the target
URI, what to do when the report URI violates its own PKP/PKP-Report-Only
policy.

The concern I have here is the disconnect between expectations. If the
site operator specifies HTTPS for a Report URI, presumably, they expect
exactly what you mentioned - that sensitive information will be protected
in transit.

If Report URIs fail the (previously stored) PKP policy, should the report
still be submitted or not? Does it match site author expectation?

A related, but subtle, implementation issue that is expected to arise if
HTTPS is allowed is ensuring that reporting loops are not formed. For
example, if submitting a report over HTTPS (via POST, presumably), and the
response data includes a PKP which the current connection violates, and a
report URI for the same URI as what was just posted, should the new
violation be reported? This can occur when the Report URI is independent
of the initial Target URI (so the second report would be unique) and when
the Report URI is identical to the Target URI (so the second report is
redundant).

My reaction to all of this is that, when the PKP header is received
following the submission of a report, that the PKP header is ignored.

This is just some of the complexity with report URIs that will need to be
worked out - although I agree with your responses, and I agree that, even
for the complexity brought, it seems like it will be a necessary and
useful part of policy configuration.

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

Re: [websec] #54: Specify a report-only mode

[Tom Ritter]

>>  On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker
>>  What are people's thoughts on this?

It hurts me to say so, because it's going to be more work and
complication and delay - but I agree a reporting system should be
added.

>>  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" ]
>>  }

I like this, although I would include the entire PKP header, the Host
header, and request URI.

On 18 October 2012 20:40, Ryan Sleevi  wrote:
>   - Should the origin of the report URI be constrained the the origin of
> the target URI?

No, you should be allowed to specify a third party domain.  I could
easily see a third party service collecting these reports as a free or
paid service.  Google Webmaster Tools may even grow into collecting it
and CSP violations.

>   - Should the report URI be allowed to specify HTTPS?

Yes.  This is potentially sensitive information, and we would like it
to be protected in transit.

>   - 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?

Honestly I don't see why not.  If it is an attacker, the attacker will
know the user rejected the TLS connection, and will have a good idea
it was because of pinning.  So what's the harm in telling them the
additional information.  Vs if it is a legit screw-up by the site,
they would still like to have the information.

> - 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.

I don't think any headers other than the PKP, Host, and URL would be needed.

>   - If the report contains validated certificates, what should the format
> be? draft-josepfsson-pkix-textual [3] may be of normative use here.

I have no opinion.

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

Re: [websec] #54: Specify a report-only mode

[Ryan Sleevi]

On Thu, October 18, 2012 5:17 pm, Chris Palmer wrote:
>  On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker
>   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

Re: [websec] #54: Specify a report-only mode

[Chris Palmer]

On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker
 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.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #54: Specify a report-only mode

[websec issue tracker]

#54: Specify a report-only mode

Changes (by palmer@…):

 * status:  new => assigned


-- 
-+---
 Reporter:  palmer@… |   Owner:  palmer@…
 Type:  defect   |  Status:  assigned
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  -|  Resolution:
 Keywords:   |
-+---

Ticket URL: 
websec 

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

[websec] #54: Specify a report-only mode

[websec issue tracker]

#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.

-- 
-+--
 Reporter:  palmer@… |  Owner:  palmer@…
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:
Component:  key-pinning  |Version:
 Severity:  -|   Keywords:
-+--

Ticket URL: 
websec 

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