> 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
