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

["Eric Lawrence" <[e-mail]>]

> 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 ; [e-mail] 
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 <[e-mail]> 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