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

[Ryan Sleevi <[e-mail]>]

On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <[e-mail]> wrote:

> I agree with Eric and Joe that the current definition of PKP-RO is not
> that useful and potentially surprising to deployers.
>
> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who
> could set pins for a lot of clients for a lot of sites could flood a
> victim with reports.


> Couldn't the MITM also set PKP pins with report-uri, or set cached
> redirects or other cached resources to generate traffic toward a
> victim?
>

Yes, and that's a user visible effect, rather than transparent. It also
requires that a connection be validated first, whereas the very definition
of PKP-RO is that you send it when a connection is not validated.


>
> Ryan argues PKP-RO is worse because it's "conceptually and practically
> silent to the user".  But once the browser has sent junk traffic to a
> victim, I don't really see how seeing how displaying a pinning error
> makes things better.
>

First, the attacker can only mount the hostile attack after having first
established a good connection. PKP-RO allows an attacker to perpetually
mount a hostile attack.
Second, the presence of a pinning error is an inherently rate-limiting
factor to the user experience. You're not going to be able to trigger 100
reports if you're causing the user 100 error pages.
Third, it seems like you're arguing for removing report-uri altogether,
given the privacy and DoS risks identified. That is, the more that  you
establish RO is similar to PKP in level of what an attacker can do, the
more it argues for removing report-URI entirely.