On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote: > Ryan - thanks for raising these issues again. I still have concerns about > getting this specific in the policy, but since we're now headed down that > road... > > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < > [email protected]> wrote: > > > A few problems I see with the proposed text: > > > > - What is sufficient? I would go with a definition tied to the effective > > strength of the keys it protects; in other words, you should protect a > > 2048bit RSA key with something that offers similar properties or that > > 2048bit key does not live up to its 2048 bit properties. This is basically > > the same CSPRNG conversation but it's worth looking at > > https://www.keylength.com/ > > > The latest proposal replaces "sufficient" with "at least 64 bits of output > from a CSPRNG". We could go back to "sufficient strength for the keys it > protects", but that also leaves quite a bit of room for misinterpretation. > > Are there objections to "at least 112 bits of output from a CSPRNG" as Tim > proposed? I'd recommend making a requirement that it be "protected" by at least as many bits of strength as the key it protects. Not doing so could cause compliance issues: things like PCI [1] and the NIST [2] recommendations require this type of protection. However, like Wayne said, this still leaves room for interpretation, if mentioning bits is necessary, can we just bump it up to 256 rather than 112?
I went back to the word "protect" to rule out the use of 3DES because bumping up the password past 112 bits doesn't really do much good if the underlying algorithm maxes out its protective strength at 112. I realize this will decrease the utility of the p12/pfx files since none of the adequately protected files would be openable on any version of Windows. However, the team at Microsoft is well aware of this and they can prioritize their own backlog (they just don't appear to have been given the right incentive to do so as of yet). Perhaps we can add a date-gate.. How about: PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password containing at least 112 bits of output from a CSPRNG, and the password SHALL be transferred using a different channel than the PKCS#12 file. Beginning January 1, 2020 PKCS#12 files must be protected by at least 256 bits of output from a CSPRNG. This would give people like Microsoft some extra time to update their implementations to support AES. -Carl [1] PCI - DSS v3.2, Section 3.5 [2] 800-57 Part 1, Section 6.2.1.3 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
