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

Chris Palmer <palmer@google.com> Fri, 04 April 2014 20:58 UTC

MIME-Version: 1.0
In-Reply-To: <CAGZ8ZG1VNHVWx2xbW_CGJvNBMmrw7vGZ5uLxCo4Si9ZPv-7ihg@mail.gmail.com>
References: <CAGZ8ZG1VNHVWx2xbW_CGJvNBMmrw7vGZ5uLxCo4Si9ZPv-7ihg@mail.gmail.com>
Date: Fri, 04 Apr 2014 13:58:30 -0700
Message-ID: <CAOuvq23ON+n10Ow1k+ikpqFwt1NMeBTV8oFtvDaBtQPPcA_rcQ@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Trevor Perrin <trevp@trevp.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/IS25l_iMgwPWD8TTdnrLPY8nwxg
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Public-Key-Pins-Report-Only
Precedence: list

On Fri, Feb 21, 2014 at 12:24 AM, Trevor Perrin <trevp@trevp.net> 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?

[websec] Public-Key-Pins-Report-Only Trevor Perrin
Re: [websec] Public-Key-Pins-Report-Only Chris Palmer
Re: [websec] Public-Key-Pins-Report-Only Trevor Perrin
Re: [websec] Public-Key-Pins-Report-Only Tom Ritter
Re: [websec] Public-Key-Pins-Report-Only Chris Palmer