Re: [websec] draft-ietf-websec-key-pinning
> 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 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
Re: [websec] draft-ietf-websec-key-pinning
On Wed, Aug 27, 2014 at 9:14 PM, Ryan Sleevi wrote: > 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: > With Ryan's proposed testing plan I fear many site operators can't easily enumerate all subdomains and even if they try this is a particularly difficult test mode because there's no feedback if you forget a subdomain. This allows you to make sure it works on all subdomains you know about-but what about the ones you don't? Beyond that though, we're probably kidding ourselves if we think most site operators will actually sit down and read an RFC front-to-back. They won't. Some evidence from a project a student of mine is working on, finding a large number of sites (~30%) are not properly setting HSTS headers per the spec (which is comparably simple to achieve): http://jbonneau.com/doc/KB14-hsts_pinning_survey_working_draft.pdf. Clearly a lot of people didn't read the RFC and that's not even counting minor errors like incorrect capitalization. I think we should be realistic that this RFC will primarily be read by developers building support into user agents and not site operators. Site operators will, at best, read somebody's 500-word how-to blog post. Many will probably just copy what some other site is doing and modify it until it appears to work. In a perfect world, we'd do "developer testing" on an draft like this where we give a random site-operator-off-the-street the RFC and ask if they can comprehend it and add support to their site. This is similar to how any new software tool should have user testing. Short of that, the evidence we have is that multiple people (including myself) who are security enthusiasts and have been following this draft for years had a broken mental model of how PKP-RO works. I think this design is violating the Principal of Least Astonishment and we're asking for trouble no matter how much explanatory text gets added to the RFC. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
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 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
Re: [websec] Re-litigating Key-Pinning
On 2014-08-27 07:44, Yoav Nir wrote: ... Fixing editorial issues like Julians’ comments about references is fine, and could even be done *after* IESG review. ... ... FWIW, I believe the ABNF issues (which are *not* editorial) absolutely need to be fixed as well. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] draft-ietf-websec-key-pinning
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
Re: [websec] Re-litigating Key-Pinning
On Aug 28, 2014, at 3:40 PM, Julian Reschke wrote: > On 2014-08-28 10:01, Yoav Nir wrote: >> >> On Aug 28, 2014, at 9:07 AM, Julian Reschke >> wrote: >> >>> On 2014-08-27 07:44, Yoav Nir wrote: ... Fixing editorial issues like Julians’ comments about references is fine, and could even be done *after* IESG review. ... ... >>> >>> FWIW, I believe the ABNF issues (which are *not* editorial) absolutely need >>> to be fixed as well. >>> >> >> Hi, Julian >> >> I don’t want to nit-pick the meaning of the word “editorial”. But anyone >> who’s read the draft knows what a PKP header looks like. I don’t think >> there’s any controversy about what is and is not a valid PKP header. So >> changing the ABNF to reflect this existing understanding, is something that >> I don’t think requires polling the group. >> ... > > The issue is that the ABNF is ambiguous about whether > > Public-Key-Pins: max-age=3000; > pin-xyz=abc; > > is syntactically valid or not. I believe it should be, because otherwise > parsers would need to special-case the "pin-*" parameters when parsing. > > Best regards, Julian Well, this might lead to me being proven wrong in my statement that everyone agrees what a valid PKP header is, but I also think this should be syntactically valid. However, clients that only support *this* document (and not “xyz and its use in key pinning”) would not pin anything based on this header. Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Re-litigating Key-Pinning
On 2014-08-28 10:01, Yoav Nir wrote: On Aug 28, 2014, at 9:07 AM, Julian Reschke wrote: On 2014-08-27 07:44, Yoav Nir wrote: ... Fixing editorial issues like Julians’ comments about references is fine, and could even be done *after* IESG review. ... ... FWIW, I believe the ABNF issues (which are *not* editorial) absolutely need to be fixed as well. Hi, Julian I don’t want to nit-pick the meaning of the word “editorial”. But anyone who’s read the draft knows what a PKP header looks like. I don’t think there’s any controversy about what is and is not a valid PKP header. So changing the ABNF to reflect this existing understanding, is something that I don’t think requires polling the group. ... The issue is that the ABNF is ambiguous about whether Public-Key-Pins: max-age=3000; pin-xyz=abc; is syntactically valid or not. I believe it should be, because otherwise parsers would need to special-case the "pin-*" parameters when parsing. Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Re-litigating Key-Pinning
On Aug 28, 2014, at 9:07 AM, Julian Reschke wrote: > On 2014-08-27 07:44, Yoav Nir wrote: >> ... >> Fixing editorial issues like Julians’ comments about references is fine, and >> could even be done *after* IESG review. ... >> ... > > FWIW, I believe the ABNF issues (which are *not* editorial) absolutely need > to be fixed as well. > Hi, Julian I don’t want to nit-pick the meaning of the word “editorial”. But anyone who’s read the draft knows what a PKP header looks like. I don’t think there’s any controversy about what is and is not a valid PKP header. So changing the ABNF to reflect this existing understanding, is something that I don’t think requires polling the group. Cheers Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
