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

[Chris Palmer <[e-mail]>]

On Tue, Aug 26, 2014 at 1:33 PM, Tom Ritter <[e-mail]> wrote:

> Well the whole threat model of HPKP (without preloading) is an
> attacker that can MITM some TLS connections, but not all of them,
> right?

"""By effectively reducing the number of authorities who can
authenticate the domain during the lifetime of the pin, pinning may
reduce the incidence of man-in-the-middle attacks due to compromised
Certification Authorities."""

The threat model is that The Alice Foundation wants to trust only
Trents 1, 4, and 9, and no other Trents, to vouch for her identity.
That way, if Trent 6 mis-issues for The Alice Foundation, Mallory
cannot make use of the mis-issued certificate in an attack.

But, yes, Mallory can still attack CarolCorp, if CarolCorp does not
use pinning or pins to Trent 6.

> Requiring PKP-RO to be on every load would allow an attacker
> to strip the header on the connections they MITM.

Only if The Alice Foundation did not also use a regular PKP header.

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

Yeah, sort of. But don't think of PKP-RO as a defense against attacks,
even if it might sometimes have that secondary benefit. It is
primarily a debugging aid for The Alice Foundation and BobCorp to get
PKP working. ("What all Trents do we need to trust, anyway?")