Re: [websec] draft-ietf-websec-key-pinning

[Tom Ritter <[e-mail]>]

On 26 August 2014 14:36, Chris Palmer <[e-mail]> wrote:
> On Mon, Aug 25, 2014 at 7:05 PM, Tom Ritter <[e-mail]> wrote:
>
>>>> No, PKP-RO is not meant to be cached. In this respect, it behaves similar
>>>> to Content-Security-Policy's reporting mechanism.
>>>
>>> Ah, interesting. I'm curious why not? Is there no use-case for allowing
>>> "report-only" pins to be persisted?
>>
>> I think there definitely are, and I and most organizations I advise
>> would like that option.
>
> What would they get from it that they would not get from just
> consistently serving the PKP-RO header?

Well the whole threat model of HPKP (without preloading) is an
attacker that can MITM some TLS connections, but not all of them,
right?  Requiring PKP-RO to be on every load would allow an attacker
to strip the header on the connections they MITM. Letting it be cached
allows an organization to put a max-age of 45 days on it, without the
risk of bricking their site if they aren't administratively competent.

Obviously an attacker can also block the reports from being sent, but
I'm hoping that the clause "In any case of report failure, the UA MAY
attempt to re-send the report later" will be considered in this case,
and that UAs will make an attempt at getting potentially blocked
reports out at a later date.

-tom