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

From: Tom Ritter <[email-masked]>
Date: Sat, 1 Mar 2014 14:17:08 -0500

On 27 February 2014 16:07, Daniel Kahn Gillmor <[email-masked]> wrote:
> On 02/27/2014 03:31 PM, Trevor Perrin wrote:
>> 1)  PKP-RO implements the full PKP semantics (i.e. is stored for max-age,
>> is applied to includeSubdomains), but only generates reports instead of
>> hard fails.  The browser would store PKP and PKP-RO pins in
>> separate/parallel stores, for example setting max-age=0 for a PKP pin would
>> not clear PKP-RO pins, and vice versa.
>>
>> 2)  PKP-RO is removed from the spec.
>>
>> 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics
>> (only check current connection).  I'm not sure about the usefulness of
>> that, and I worry site operators would be mislead by it.
>
> As someone who sometimes helps to operate and plan the operation of web
> sites, i don't think the semantics of (3) are misleading, but they're
> not particularly confidence-inspiring either.
>
> What is the goal of PKP-RO?  Is the goal to encourage adoption by giving
> site operators confidence in a proposed configuration or organizational
> workflow?

As I believe - this. PKP-RO doesn't enforce security for a site, and
while a PKP header MAY be saved for later reporting* - an attacker
performing a man-in-the-middle attack can block a PKP-RO assignment or
a PKP-RO report. (At least, right now, I have a suggestion for this
below.)

* From http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3

So I feel it's primarily for testing a configuration and gaining
confidence in it before rolling it out.

> The real footgunnery with PKP will come during key transition/rollover
> (or switching CAs), as clients who have cached pins cope with the
> changes.   Using (3)-style PKP-RO to build confidence in an
> organizational workflow around this kind of transition event doesn't
> seem possible.

I agree.

So I'm for #1 - store it.  I have afew suggestions around fixing up
portions of the doc for this.

The PKP-RO header MUST be able to be cleared out at any time by
setting max-age=0 if the connection occurs over an error-free TLS
connect excepting any requirement of matching a key to a PKP-RO
header.  Explained, I should be able to clear out an old PKP-RO header
even if I set the hash to DEADBEEF and the max-age to a year.

The PKP-RO header reports MAY be stored for reporting at another time.
I don't think browsers will implement this right away, but down the
line I think it might turn into an actual security feature.  A report
SHOULD be generated and transmitted (or stored) before clearing out an
old policy.  (So bad is I get an extra report I ignore, good is that
an attacker can't definitively silence a report if it is stored for
later.)

When I recieve reports, I can tell what the PKP-RO policy was at the
time by examining the report.  Except that the report needs to have a
new field in there saying if it's mode is 'enforcement' or
'report-only'.  As a site operator, I can even go farther by
specifying a non-hash such as sha256=policytest20140301v1 - no one
will be able to gen a cert that hashes to a b64 representation of
that, and it lets me track my policy deployments if I like.

-tom

---

From: Chris Palmer <[email-masked]>
Date: Mon, 3 Mar 2014 13:46:11 -0800

Hi all, status note: I was very busy last week and I will be this week
too, but I'm going to try to get another revision out late this week.
But I can't promise to, unfortunately. But I am watching this thread,
and not forgetting about this issue.

On Sat, Mar 1, 2014 at 11:17 AM, Tom Ritter <[email-masked]> wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec