Subject: Re: [websec] Public-Key-Pins-Report-Only

From: Chris Palmer <[email-masked]>
Date: Fri, 4 Apr 2014 13:58:30 -0700

On Fri, Feb 21, 2014 at 12:24 AM, Trevor Perrin <[email-masked]> wrote:

> How should HPKP's Public-Key-Pins-Report-Only header work?
>
> Does it only apply a check to the current TLS connection, or is the UA
> is expected to remember the pins and apply them to future connections?
>
> If the UA is expected to remember them, how do "Report-Only" pins
> interact with regular pins?  Do they override each other or are
> Report-Only pins tracked separately, so that a browser might have a
> Report-Only pin and a "regular" pin for the same site?

Good question, thanks. I've tried to answer it in the latest rev of
the draft (https://code.google.com/p/key-pinning-draft/):

=====

<t>When used in the Public-Key-Pins-Report-Only header, the UA SHOULD POST
reports for Pin Validation failures to the indicated report-uri, although
the UA MUST NOT enforce Pin Validation. That is, in the event of Pin
Validation failure when the host has set the Public-Key-Pins-Report-Only
header, the UA performs Pin Validation only to check whether or not it
should POST a report, but not for causing connection failure.</t>

<t>If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note
the Pins and directives given in the Public-Key-Pins-Report-Only header. If
the UA does note the Pins and directives in the Public-Key-Pins-Report-Only
header it SHOULD evaluate the specified policy and SHOULD report any
would-be Pin Validation failures that would occur if the report-only policy
were enforced.</t>

<t>If a Host sets both the Public-Key-Pins header and the
Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin
Validation as specified by the Public-Key-Pins header, and SHOULD note the
Pins and directives given in the Public-Key-Pins-Report-Only header. If the
UA does note the Pins and directives in the Public-Key-Pins-Report-Only
header it SHOULD evaluate the specified policy and SHOULD report any
would-be Pin Validation failures that would occur if the report-only policy
were enforced.</t>

<t>When used in the Public-Key-Pins header, the presence of a report-uri
directive indicates to the UA that in the event of Pin Validation failure it
SHOULD POST a report to the report-uri, in addition to terminating the
connection (as described in <xref
target="validating-pinned-connections"/>).</t>

=====

Does that clarify?

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 5 Apr 2014 11:37:14 -0700

> target="validating-pinned-connections"/>).</t>

I think your intent is that there's 2 different types of pins (regular
and report-only), which don't interact.  I.e. setting max-age=0 on a
regular PKP header doesn't clear PKP-RO pins, and vice versa.  And
when contacting a pinned site, the UA might have to apply both pins to
it.

Seems reasonable, if other people agree.

Regarding the specific text, my guess is this will need more changes
to make clear, since the document was mostly written from the
perspective of there only being 0 or 1 "pins" for a connection.  But
I'd have to re-read it to make sure.

Trevor

---

From: Tom Ritter <[email-masked]>
Date: Mon, 7 Apr 2014 09:29:15 -0400

> Seems reasonable, if other people agree.

That is my take on it as well, and what I desired.  I think the
wording needs to be clarified significantly however. All of the logic
around the interaction of PKP and PKPRO is buried in the report-uri
subsection.  I would suggest a new 2.3.2 and change the report-uri
section.  Textual Suggestions:

My thoughts on the report-uri section:

<section anchor="report-uri" title="The report-uri Directive">

<t>The OPTIONAL "report-uri" directive indicates the URI to which the UA
SHOULD report Pin Validation failures (<xref
target="validating-pinned-connections"/>). The UA POSTs the reports to the
given URI as described in <xref
target="reporting-pin-validation-failure"/>.</t>

<t>When used in the Public-Key-Pins or Public-Key-Pins-Report-Only header,
the presence of a report-uri
directive indicates to the UA that in the event of Pin Validation failure it
SHOULD POST a report to the report-uri.  If the header is Public-Key-Pins,
the UA should do this in addition to
terminating the connection (as described in <xref
target="validating-pinned-connections"/>).</t>

<t>Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If the
scheme in the report-uri is HTTPS, UAs MUST perform Pinning Validation when
the host in the report-uri is a Known Pinned Host; similarly, UAs MUST apply
HSTS if the host in the report-uri is a Known HSTS Host.</t>

<t>Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the Known Pinned Host.</t>

<t>UAs SHOULD make their best effort to report Pin Validation failures to
the report-uri, but may fail to report in exceptional conditions. For
example, if connecting the report-uri itself incurs a Pinning Validation
failure or other certificate validation failure, the UA MUST cancel the
connection (and MAY attempt to re-send the report later). Similarly, if
Known Pinned Host A sets a report-uri referring to Known Pinned Host B, and
if B sets a report-uri referring to A, and if both hosts fail Pin
Validation, the UA SHOULD detect and break the loop by failing to send
reports to and about those hosts.</t>

<t>UAs SHOULD limit the rate at which they send reports. For example, it
is unnecessary to send the same report to the same report-uri more than
once.</t>

<!--
I disagree or misunderstand with this, will send a separate email:
<t>UAs MUST NOT send a report if the Host is not already a Known Pinned
Host. (I.e., the UA's first connection to a Host fails Pin Validation.) The
reason for this is so that a potential active network attacker cannot learn
about a UA's certificate validation and Pin Validation procedures and
state.</t>
-->

</section><!-- report-uri -->

New 2.3.2

Interaction of Public-Key-Pins and Public-Key-Pins-Report-Only

A server MAY set both the Public-Key-Pins and Public-Key-Pins-Report-Only
headers simultaneously. The headers do not interact with one another but
the UA MUST process the Public-Key-Pins header and SHOULD process both.

The Public-Key-Pins header is processed as according to section 2.3.1.

When the Public-Key-Pins-Report-Only header is used with a report-uri, the
UA SHOULD POST reports for Pin Validation failures to the indicated
report-uri, although the UA MUST NOT enforce Pin Validation. That is,
in the event of Pin Validation failure when the host has set the
Public-Key-Pins-Report-Only header, the UA performs Pin Validation
only to check whether or not it should POST a report, but not for causing
connection failure.</t>

Note: There is no purpose to using the Public-Key-Pins-Report-Only header
without the report-uri directive. User Agents MAY discard such headers
without interpretting them further.

<t>If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD note
the Pins and directives given in the Public-Key-Pins-Report-Only header as
specified by the max-age directive. If
the UA does note the Pins and directives in the Public-Key-Pins-Report-Only
header it SHOULD evaluate the specified policy and SHOULD report any
would-be Pin Validation failures that would occur if the report-only policy
were enforced.</t>

---

From: Chris Palmer <[email-masked]>
Date: Mon, 28 Apr 2014 15:23:14 -0700

Thank you very much Tom! I've adopted your text:

https://code.google.com/p/key-pinning-draft/source/detail?r=399853be11c34f6621cfc9b9de35db44d819be98

As for:

<!--

we'll follow up about that in the separate thread.