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 From: Ryan Sleevi Sent: Wednesday, August 27, 2014 8:14 PM To: Tom Ritter Cc: Yoav Nir ; draft-ietf-websec-key-pinning ; Eric Lawrence ; mailto:websec@ietf.org Subject: Re: [websec] draft-ietf-websec-key-pinning Right, so, I do agree with Joe that I do think we've reached conclusions on the suitability for security and the suitability for testing, and I do want to see what can be done to editorially resolve this. Without having fully drafted the text, it seems like one possible solution is to describe HOW a site operator might use this to test deployment of pins, knowing that it may not be a perfect solution for all use cases, it would at least help to clarify both the strengths and limitations. The example I'm thinking of is as follows: -- Begin Site operator deploys PKP-RO on their domain - In order for this to be useful, the assumption here (and which I think had always been implicit, but it may help to call this out, in several places if necessary) is that PKP-RO does not require that the current connection MATCH the pins in order to send a report (otherwise, you'd never get a negative report, because you'd never evaluate PKP-RO in the negative case) - They gather data from their users, which may include information about possible certificate chain paths that they were not aware of (assuming a publicly trusted CA with UAs with different trust stores, etc) After gathering data, they deploy PKP, which makes the RO now a hard fail. They may still use report-uri with their PKP header, along with shorter timeframes, to ensure no critical errors were missed Now it comes time to gather in the sub-domains, the site operator works through their (known) subdomains with PKP-RO, doing the same steps as they did for the parent domain, setting PKP on these subdomains. Believing they have gathered all their subdomains into a unified policy, they then work to set PKP on the 'main' domain with includeSubDomains + reportURI set. They likely do this in small bursts, temporarily decreasing the max-age of the 'main' domain when setting the includeSubDomains (e.g. perhaps 1 day or even 4-12h), examining reportURI for failures, and then turning on their sans-includeSubDomains policy with the longer max-age Finally, believing to have gathered sufficient data, they turn on includeSubDomains (with report-URI), and have the whole system protected -- Fin As Eric noted in HSTS, this may include having the subdomains either set their own policies (for redundancy/safety, but at the tradeoff of potentially conflicting pin policies, as already noted), or having the subdomains source a resource from the parent domain (which causes them to fetch/detect the includeSubDomains from the parent domain) The assumption here, and I realize is perhaps unfair for some use cases, is that you know the sub-domains you wish to protect. Hopefully a competant domain administrator was responsible and this information can be discovered. The short-lived PKP+includeSubDomains+reportUri provides an added means of testing, but is admittedly 'more' heavy-handed than simply PKP-RO with persistence. PKP-RO with persistence is, I think, dangerous. In the naieve form, it allows a MITM to setup a DOS bomb against a legitimate server, by setting a PKP-RO to report errors. Unlike a PKP policy (which is detectable by the user, by virtue of fail-closed), whose fail-closed nature may indicate to the user that somebody set them up a bomb, a PKP-RO is conceptually and practically silent to the user, which may cause the user to flood the legitimate server with reports once they're away from the MITM. Now, we could tweak how persistence works for that case, but I think as we do, we get further and further into a complexity that may require significant edits/reviews. We can do that, but I gather the spirit, both of the editors and, from the responses, those involved in this discussion, that it's not necessarily something felt too strongly about. The question is, does the above scenario sound reasonable enough to include, perhaps in an "operational advice" or some form of appendix, that provides guidance on how the existing primitives can be used, but also highlights the limitations of the current primitives so as not to cause confusion? On Wed, Aug 27, 2014 at 5:26 AM, Tom Ritter <t...@ritter.vg> wrote: On 27 August 2014 05:46, Yoav Nir <ynir.i...@gmail.com> wrote: > At this stage, we can make editorial changes, but we cannot make significant > changes on our own. We can withdraw the request to publish, and take it back > to the working group, but I think that would be inadvisable. > > I think we should proceed, making only editorial changes, and changes > resulting from discussion with IESG members. If adding a note in 4.2 about includeSubdomains and PKP-RO (for testing) counts as editorial, I think that is worthwhile. Otherwise/regardless I also don't want to withdraw. -tom
_______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
