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

[Trevor Perrin <[e-mail]>]

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 <[e-mail]> 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 ;
> [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
>
>
>
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec
>