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? 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. Trevor On Thu, Aug 28, 2014 at 9:13 AM, Eric Lawrence <ericlaw1...@hotmail.com> wrote: >> testing with PKP-RO may >> be fine before first deploying PKP, but it doesn’t help you where it’s >> dangerous - >> when it’s time to change certificates. > > In addition to raising confidence before you first deploy, PKP-RO helps when > you wish to retire a pinned SPKI. > > For instance: > > 0. Acme Corp has a secure website; they’re using PKP with > includeSubdomains. > 1. Acme Corp currently buys its certs from Verisign and uses PKP to pin > the Verisign intermediate SPKI. > 2. Next year, Acme Corp decides that they want to buy GoDaddy certs > instead. They update their PKP header to add the GoDaddy intermediate’s SPKI > to the list. > 3. Because Acme Corp is a huge enterprise, they don’t know if some > business unit (e.g. SpecialProjects.Acme.com) didn’t get the memo about the > move to GoDaddy and may still be using a Verisign cert. So, in addition to > the updated PKP header, they ALSO send a PKP-RO header that specifies *only* > the GoDaddy SPKI and watch for any reporting failures. > 4. After an appropriate period, Acme concludes that they are safe in > replacing the PKP set of SPKIs with the set they prototyped in PKP-RO. They > do so and remove the PKP-RO header. > > -Eric > > *An aside vis-à-vis the plausibility of #3, a site not knowing about its own > subdomains: I recently spoke to a site (“example.com”) that wasn’t using > includeSubdomains on their HSTS header. I asked why not, since all of the > company’s public websites were HTTPS. It turns out that they can’t use > includeSubdomains because their private Intranet uses internally-mapped > domains subordinate to their public domain name suffix. So, while > “hr.example.com” isn’t publicly reachable, browsers don’t know or care, and > HSTS+includeSubdomains will fail any insecure connection for the employees > inside the company. > > A similar challenge will face any such companies when they try to use PKP > with includeSubdomains. > > > From: Yoav Nir > Sent: Thursday, August 28, 2014 9:59 AM > To: Eric Lawrence > Cc: Ryan Sleevi ; Tom Ritter ; draft-ietf-websec-key-pinning ; > websec@ietf.org > Subject: Re: [websec] draft-ietf-websec-key-pinning > > Hi Eric > > Part of the issue is that PKP (and PKP-RO) follow the lead of other headers > such as CSP that also have report-only alternatives, but PKP is inherently > different. > > CSP has directives that relate to the content delivered, so if CSP has a > directive that says the resource cannot be displayed behind a transparent > floating frame, the content will not be displayed. If it’s CSP-RO instead of > CSP, the content is displayed, but a report is also sent. That makes sense, > and if you see that the CSP-RO header causes reports, you can adjust it. > Once you move to CSP, you’re fine as long as the content does not change, > and even if it does change, you can test it first with a test server. > > For PKP it’s different. The thing that changes is the certificate presented > to the client. You can’t test the new certificate on a side server, at least > not in a way that will fill you with confidence. And because of the way > certificates are used, there is no such thing as a static structure to the > site. You have to change the certificate (and usually the key) every year, > so testing with PKP-RO may be fine before first deploying PKP, but it > doesn’t help you where it’s dangerous - when it’s time to change > certificates. > > This leads some people around here to conclude that PKP-RO is not useful. > > Yoav > > > On Aug 28, 2014, at 5:26 PM, Eric Lawrence <ericlaw1...@hotmail.com> wrote: > > I’ll take one last tilt at this, because I think this spec is quite > important and folks aren’t actually very far apart on this. > > To start, I want to reiterate that Draft #20 was the first time I got > involved in PKP, so my perspective comes from that draft and not any other > conversations, tribal knowledge, meetings, etc, that others in the group may > have been a part of. > > Here’s how I *thought* Draft #20 specified things to work: > > 1> PKP and PKP-RO are equivalent in every way except that PKP mismatch > triggers a Report *and* fails the connection, while PKP-RO mismatch only > triggers a Report. That’s why PKP-RO is named “Public Key Pins Report Only” > and not “Sorta Like Public Key Pins But Does Not Break Connections And Does > Not Persist (SLPKPBDNBCADNP)” > > 2> Site administrators should use PKP-RO to prototype a policy to be later > deployed PKP. They use PKP-RO first to generate confidence that they will > not be self-inflicting any broad denial-of-service when enabling PKP. > > 3> When PKP and PKP-RO headers are initially encountered (pins not > previously stored), a failure to match the specified policy triggers a > Report. The mismatched policy is NOT stored, which blocks the DOS bomb > attack Ryan mentions below. > > 4> PKP and PKP-RO only exist as different headers because it allows a site > to have one policy in force and also prototype proposed policy changes. > > This design made perfect sense to me, and my feedback on the draft was > primarily intended to clarify the language around this design. > > Instead, it appears that PKP-RO works dramatically differently than PKP, in > ways that I believe are entirely non-obvious to implementers who only read > the draft. While I believe it would be possible to editorially change the > language to make PKP-RO’s different behavior, to me, that approach only > seems to be codifying a more confusing, less useful design, and would > require more work on the part of the authors. > > I don’t believe there are any privacy or security implications in allowing > PKP-RO to behave like PKP except that it’s “Report Only.” Any privacy or > security implications in PKP-RO are shared by PKP. > > -Eric Lawrence > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
