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

[Yoav Nir <[e-mail]>]

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