Re: FW: P-521
On 05/07/17 11:40, Arkadiusz Ławniczak wrote: > As CERTUM, we are not aware of any implementations which do not > support P-521 (with the exception of BoringSSL where P-512 is > disabled but not unsupported). Yes, but that means that whenever Chrome uses BoringSSL, your roots won't work, right? Is that not a problem for you? >> From a cryptosystem security point of view - especially rootCA and >> ARL - P384 to P521 is like "day to night". This is particularly >> important for crypto-systems to be safe for decades. As noted in my previous message, you need to provide some backup for that assertion. > The key is: "or higher". The thing is the vendors'/browsers' policies > should be consistent with the functioning of the market and therefore > we belive that removing P-521 from Mozilla Policy was not a good > thing. "The market" is overwhelmingly not using P-521, according to the statistics quoted in this discussion. If we allow it and it starts being used, every web client SSL implementation will need to carry this algorithm for the forseeable future. Given that there are other new, probably-better curves and algorithms coming down the pipe, it seems unwise to pad out the compulsory set with yet more variants on the same thing. So pending a very good argument why P-521 provides something that neither the existing algorithms nor the new class of pending algorithms can provide, I think we will leave the policy as-is. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
On 06/07/17 16:20, Ryan Sleevi wrote: > compelling to add support for, and the security boundary between 192-bits > and 256-bits is somewhere in the "heat death of the universe" level > security (see > https://www.imperialviolet.org/2014/05/25/strengthmatching.html ) Perhaps this is the discussion we need to be having, because Arkadiusz asserted the difference was "night and day". Arkadiusz: do you have backing for your assertion that P-521 has meaningfully improved levels of security over P-384? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
On Thu, Jul 6, 2017 at 10:46 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/07/17 14:49, Alex Gaynor wrote: > > Is it really true that additional curves are just additional parameters? > I > > That was my assumption; additional clue on this point would be welcome. As Alex mentioned - it's generally not the case. While you can implement with generic parameters, this can create both security and performance issues, and so the preference within cryptographic libraries is to maintain optimized versions (optimized for constant time, which is not always easy, but also optimized for performance). For NSS, consider the contributions from Intel - https://bugzilla.mozilla.org/show_bug.cgi?id=1073990 , the performance analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1125028 , the performance optimizations in https://bugzilla.mozilla.org/show_bug.cgi?id=653236 , and the performance issues in https://bugzilla.mozilla.org/show_bug.cgi?id=1293936 . In short, it generally gravitates towards per-platform, per-curve optimizations. I think it's also worthwhile to consider the performance impact - https://www.imperialviolet.org/2010/12/21/eccspeed.html . Note where P-521 falls on that graph. While this is 7 years ago, the numbers have not (to my knowledge) substantially improved in relation to eachother. It's also useful to think of this similar to RSA. The Baseline Requirements do not set a maximum bound on the RSA modulus size - merely specifying a minimum of 2048. However, in practice, >= 8096 is not supported, due to limitations that many platforms impose, due to the computational cost. So the Web PKI does determine an effective limit, even if NSS supports up to 16K RSA moduli sizes (but imposes 16K as the limit, again, for performance reasons). So the Web PKI certainly imposes limits - for performance, security, and interoperability - so it's not unreasonable to impose this same limit. The performance gulf, and the added overhead, do not make it significantly compelling to add support for, and the security boundary between 192-bits and 256-bits is somewhere in the "heat death of the universe" level security (see https://www.imperialviolet.org/2014/05/25/strengthmatching.html ) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
On 05/07/17 14:49, Alex Gaynor wrote: > Is it really true that additional curves are just additional parameters? I That was my assumption; additional clue on this point would be welcome. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I agree crypto algorithms are not "gotta catch 'em all", but the > algorithm is ECDH, which NSS must implement anyway to support P-256 and > P-384, and a curve is just another set of parameters to it. I also think > that there is little value and there is potential confusion (as we have > seen) in Mozilla mandating a more restrictive set than the BRs and than > Microsoft: > Is it really true that additional curves are just additional parameters? I haven't gone source-diving in NSS recently, but my understanding is that most crypto libraries provide optimized assembly routines for scalar multiplication on a per-curve basis -- OpenSSL appears to have over 10,000 lines of assembly-generating-perl for P256 alone ( https://github.com/openssl/openssl/tree/master/crypto/ec/asm). Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
I agree crypto algorithms are not "gotta catch 'em all", but the algorithm is ECDH, which NSS must implement anyway to support P-256 and P-384, and a curve is just another set of parameters to it. I also think that there is little value and there is potential confusion (as we have seen) in Mozilla mandating a more restrictive set than the BRs and than Microsoft: > NIST FIPS PUB 186-4 recommends 4 curves over Prime Fields for use in US > public administration. These are: > P-192, P-256, P-384, P-521 > > Baseline Requirements require: > P-256,P-384 or P-521 > > Key Requirements for Microsoft Trusted Root Program: > P-256, P-384, P-521 > > Mozilla Root Store Policy: > P-256, P-384 If there are, or become, interoperability issues in practice, then I think we can leave that as the CA's lookout. So I am currently minded to restore P-521 to the Mozilla permitted list. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
