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

[Trevor Perrin <[e-mail]>]

On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi <[e-mail]> wrote:
>
>
>
> 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.

Hmm, there's nothing clever that can be done with cached javascript or
html to also generate silent traffic toward a victim?


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

I'd expect stored PKP-RO to follow the same rules as PKP and be stored
only if it meets the bullet points in 2.5 (error-free TLS connection,
backup pins, etc.).

It would make sense for any report-uri header (PKP or PKP-RO) that
fails the 2.5 checks, or has some other invalid syntax (eg bad
base64), to *also* generate a different sort of report and not be
stored.

Would it be reasonable to add a reporting message for 2.5 failure or
syntax failure?  Otherwise, when asserting a report-uri pin you can't
distinguish pin-not-stored errors from
pin-stored-and-validation-successful.


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

Debateable per above.


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

Rate-limiting is already proposed:
"""
UAs SHOULD limit the rate at which they send reports.  For example,
   it is unnecessary to send the same report to the same report-uri more
   than once per distinct set of declared Pins.
"""

Wouldn't that take care of it?


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

Dunno.  I'm still trying to understand these risks, whether they're
really different for PKP-RO vs PKP, and for HPKP versus other web
technologies.

Trevor