It has generally been understood that a string still "contains at least 112 bits of output from a CSPRNG" if that string has been fed through an encoding mechanism like Base64 or Base32.
Furthermore, explicit requirements about including mixed case or special
characters leads to some very, very bad and borderline toxic security
requirements. NIST has recently recanted and admitted they were very, very
wrong in this area and we should not repeat their mistake.
Anything we can do to clarify that an awesome password is:
string password = Base32.Encode(CSPRNG.ReadBytes(n));
where n >= 112, we should do.
BTW United Airlines rates these sorts of passwords as "medium strength".
Password meters that only pay attention to password complexity and not
length are stupid.
-Tim
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of
Buschart,
> Rufus via dev-security-policy
> Sent: Thursday, May 3, 2018 6:01 PM
> To: Carl Mehner <c...@cem.me>; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
>
> Basically I like the new wording:
>
> > PKCS#12 files [...] SHALL have a password containing at least 112 bits
> > of output from a CSPRNG, [...]
>
> But I think there is a practical problem here: Directly using the output
of any
> random number generator ("C" or not) to generate a password will lead to
> passwords which contain most probably characters that are either not
> printable or at least not type-able on a 'normal' western style keyboard.
> Therefore I think we need to reword the password strength section a little
bit,
> maybe like the following:
>
> > PKCS#12 files [...] SHALL have a 14 character long password consisting
> > of characters, digits and special characters based on output from a
> > CSPRNG, [...]
>
> When I originally proposed my wording, I had the serial numbers in my mind
> (for which directly using the output of a CSPRNG works), but didn't think
on the
> encoding problem.
>
>
> With best regards,
> Rufus Buschart
>
> Siemens AG
> Information Technology
> Human Resources
> PKI / Trustcenter
> GS IT HR 7 4
> Hugo-Junkers-Str. 9
> 90411 Nuernberg, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> www.twitter.com/siemens
>
> www.siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
Hagemann
> Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
> Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik
Neike,
> Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich,
Germany;
> Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
> WEEE-Reg.-No. DE 23691322
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: dev-security-policy
> > [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> > ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
> > Gesendet: Mittwoch, 2. Mai 2018 07:45
> > An: mozilla-dev-security-pol...@lists.mozilla.org
> > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
> > to policy
> >
> > 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 <
> > > dev-security-policy@lists.mozilla.org> 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://clicktime.symantec.com/a/1/MiD2ZQaRtfOOhnoE5EIpI34AP9rvA3o
> > > >
> INRRu6XdViYU=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZm
> k
> > > > H2jvdL5ebp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmva
> > > > pCtr5kNgTYlIotEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0
> > > > b_wYIQDNW12oF8hKmnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNR
> > > > VIAGL4FEFLugnwgUwhflFoN1ujWwINVoDV10imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rd
> > > > G73BizNHiOU8uKepckQXTmYUBYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ld
> > > >
> Pxgq1WlnDDzMiQmsQ0cVAf8MZCcYw8WTa6ax_O7cku54_qoiUKm4qq2Mgj2iz
> UKJ78
> > > > paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLxh6QXvaobBri_WOyMUZmrh_tMbpRawssbZY
> > > >
> hA9x1BzLG3a6eWSDgd0MAvNrzh2qCrnGXlSkM6wzvQ%3D%3D&u=https%3A%
> 2F%2Fw
> > > > ww.keylength.com%2F
> > >
> > >
> > > 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://clicktime.symantec.com/a/1/yOtKtPRlJaGiO5FMMDvh-
> qKgjiBUYZ65OBr
> >
> 7YB5wT7k=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZmkH2j
> vdL5e
> > bp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmvapCtr5kNgTYlI
> > otEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0b_wYIQDNW12oF8hK
> > mnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNRVIAGL4FEFLugnwgUwhfl
> > FoN1ujWwINVoDV10imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rdG73BizNHiOU8uKepckQXTmYU
> > BYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ldPxgq1WlnDDzMiQmsQ0cVAf8MZCcY
> >
> w8WTa6ax_O7cku54_qoiUKm4qq2Mgj2izUKJ78paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLx
> >
> h6QXvaobBri_WOyMUZmrh_tMbpRawssbZYhA9x1BzLG3a6eWSDgd0MAvNrzh
> 2qCrnGXlSk
> >
> M6wzvQ%3D%3D&u=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2FSpecia
> lPubl
> > ications%2FNIST.SP.800-57pt 1r4.pdf
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> >
> https://clicktime.symantec.com/a/1/M0LorXtyz72F0Xke0nsBMZOIWokxRGoxK
> xY
> >
> pHIY6kec=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZmkH2jv
> dL5e
> > bp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmvapCtr5kNgTYlI
> > otEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0b_wYIQDNW12oF8hK
> > mnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNRVIAGL4FEFLugnwgUwhfl
> > FoN1ujWwINVoDV10imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rdG73BizNHiOU8uKepckQXTmYU
> > BYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ldPxgq1WlnDDzMiQmsQ0cVAf8MZCcY
> >
> w8WTa6ax_O7cku54_qoiUKm4qq2Mgj2izUKJ78paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLx
> >
> h6QXvaobBri_WOyMUZmrh_tMbpRawssbZYhA9x1BzLG3a6eWSDgd0MAvNrzh
> 2qCrnGXlSk
> > M6wzvQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> securi
> > ty-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/M0LorXtyz72F0Xke0nsBMZOIWokxRGoxK
> xYpHIY6kec=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZmkH2
> jvdL5ebp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmvapCtr5kNgTYlIotEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0b_wYIQDNW12oF8hKmnVApkn0sJ
> xGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNRVIAGL4FEFLugnwgUwhflFoN1ujWwINVoDV10
> imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rdG73BizNHiOU8uKepckQXTmYUBYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ldPxgq1WlnDDzMiQmsQ0cVAf8MZCcYw8WTa6
> ax_O7cku54_qoiUKm4qq2Mgj2izUKJ78paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLxh6QXvaobBri_WOyMUZmrh_tMbpRawssbZYhA9x1BzLG3a6eWSDgd
> 0MAvNrzh2qCrnGXlSkM6wzvQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
