On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi <sle...@google.com> wrote: > > > > On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <tr...@trevp.net> 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 _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
