P-521

[Gervase Markham]

This issue seems to come up regularly, and I can never find the
discussion I'm sure we had about it, so I'm starting a thread here with
"P-521" in the subject so it'll be clear.

Should we be permitting use of this curve in our policy?

I removed it from the policy in
https://github.com/mozilla/pkipolicy/issues/5 because I was under the
impression that Firefox and/or NSS didn't support it. But I now see (not
sure how I didn't notice before) that the relevant bugs are unfixed or
WONTFIXed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1129077
https://bugzilla.mozilla.org/show_bug.cgi?id=1128792

And I notice that the P-521/SHA-512 combination is recommended, or at
least specced, in TLS 1.3:
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.3

But it seems like BoringSSL doesn't support it:
https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2

So what should we be doing in our policy (which, by principle, looks to
Mozilla's needs first)? Banning it? Discouraging it but allowing it?
Permitting it? Something else?

Gerv

[Kurt Roeckx]

On 2017-06-27 15:51, Gervase Markham wrote:
> This issue seems to come up regularly, and I can never find the
> discussion I'm sure we had about it, so I'm starting a thread here with
> "P-521" in the subject so it'll be clear.
>
> Should we be permitting use of this curve in our policy?

I suggest you keep it for now.

You should probably allow ed25519 and ed448.


Kurt

[Gervase Markham]

On 27/06/17 07:17, Kurt Roeckx wrote:
> I suggest you keep it for now.

An opinion without a rationale is not all that useful :-)

Gerv

[Kurt Roeckx]

On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote:
> On 27/06/17 07:17, Kurt Roeckx wrote:

> > I suggest you keep it for now.
>

> An opinion without a rationale is not all that useful :-)

A lot of software supports it, including NSS / Firefox. It's not
an ideal curve, and it should get replaced, but it's currently
better to have it then not.

I currently only count 222 certificate using P-521 that chain to
the Mozilla root store, and I guess some of those would fall back
to RSA.

I see no reason to say that they shouldn't be used at this time.


Kurt

[Alex Gaynor]

I'll take the opposite side: let's disallow it before it's use expands :-)
P-521 isn't great, and there's really no value in proliferation of crypto
algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't
try to catch 'em all". There's no real use cases P-521 enables, and not
supporting it means one less piece of code to drag around as we move
towards better curves/signature algorithms like Ed25519 and co.

Alex

On Tue, Jun 27, 2017 at 2:40 PM, Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote:
> > On 27/06/17 07:17, Kurt Roeckx wrote:

> > > I suggest you keep it for now.
> >

> > An opinion without a rationale is not all that useful :-)
>
> A lot of software supports it, including NSS / Firefox. It's not
> an ideal curve, and it should get replaced, but it's currently
> better to have it then not.
>
> I currently only count 222 certificate using P-521 that chain to
> the Mozilla root store, and I guess some of those would fall back
> to RSA.
>
> I see no reason to say that they shouldn't be used at this time.
>
>
> Kurt
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Tom .]

On 27 June 2017 at 11:44, Alex Gaynor via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> I'll take the opposite side: let's disallow it before it's use expands :-)
> P-521 isn't great, and there's really no value in proliferation of crypto
> algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't
> try to catch 'em all". There's no real use cases P-521 enables, and not
> supporting it means one less piece of code to drag around as we move
> towards better curves/signature algorithms like Ed25519 and co.

But is that what we're talking about? I didn't think the question was
"Should we remove P-521 code from NSS" it's "Should we permit CAs to
use P-521?"

Limiting the policy to restrict P-521 would probably not affect the
code at all - a self-signed cert that uses it will still trigger the
code most likely (unless we were particularly clever about not hitting
those code paths until after the user trusted a self-signed cert.)

-tom

[Peter Gutmann]

Alex Gaynor via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>I'll take the opposite side: let's disallow it before it's use expands :-)
>P-521 isn't great, and there's really no value in proliferation of crypto
>algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't
>try to catch 'em all".

"Elliptic Curve Cryptography in Practice", FC'14, for SSH P256 support is
99.9%, P521 support is 0.01%, P384 support is 0.00%. So you can pretty much
just assume that if it supports ECC, it'll be P256.

Peter.

[Ryan Sleevi]

On Tue, Jun 27, 2017 at 2:44 PM, Alex Gaynor via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I'll take the opposite side: let's disallow it before it's use expands :-)
> P-521 isn't great, and there's really no value in proliferation of crypto
> algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't

> try to catch 'em all". There's no real use cases P-521 enables, and not
> supporting it means one less piece of code to drag around as we move
> towards better curves/signature algorithms like Ed25519 and co.

+1 to this.

P-521 is specified for negotiation because negotiation is just that -
negotiation. It's not mandatory to implement all of those algorithms, and
it's not necessarily desirable to either (e.g. rsa_pkcs1_sha1 )

P-521 does not have widespread deployment on the Web PKI, and does not
meaningfully or substantially improve security relevant to the attacks, at
a computational and interoperability cost that is justified.

[Arkadiusz Ławniczak]

Hello all

As CERTUM, we would like to create and submit to Mozilla our two new root CAs. There would be nothing unusual about this but I've found that Mozilla Policy doesn't allow to use algorithm P-521 and that is what we want to use in our root CA.

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

P-256, P-384 and P-521 curves are commonly implemented in all popular cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware cryptographic modules.

But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has limited its policy to only two curves P-256 and P-384.
The reasons for this decision are known only to this agency and Mozilla. It can be assumed that stronger cryptography is currently embarrassing for the NSA, and the safety margin over the operation time is low.
>From the point of view of Certum CA, the two alleged reasons are irrelevant.

This is true that, according to NSA "Suite B" recommendations, standards have been developed such as:

1) IETF RFC 6460, for TLS
2) IETF RFC 6379, for IPsec
3) IETF RFC 6318, for SMIME
4) IETF RFC 5759, for X.509 certificate and CRL

However, we must recognize that X.509 end entities and service certificates are issued for one year, up to three years. CA root certificates are issued for 25 years. They must rely on stronger cryptography as well as the ARLs they publish.

Not every commercial organization must also apply to NSA recommendations and its depleted cryptographic algorithms. Especially if it operates in Europe and cares for the safety of its customers.

--
Arkadiusz Ławniczak
Analyst
Security and Trust Services Division
Asseco Data Systems S.A.
Biuro w Szczecinie
ul. Królowej Korony Polskiej 21
70-486 Szczecin
mob. +48 669992104
arkadiusz...@assecods.pl
assecods.pl

[Gervase Markham]

On 29/06/17 00:11, Arkadiusz Ławniczak wrote:
> P-256, P-384 and P-521 curves are commonly implemented in all popular cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware cryptographic modules.

Are you aware of any libraries or browsers which do not support P-521?

> But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has limited its policy to only two curves P-256 and P-384.
> The reasons for this decision are known only to this agency and Mozilla. It can be assumed that stronger cryptography is currently embarrassing for the NSA, and the safety margin over the operation time is low.

Do you believe that P-521 is usefully stronger than P-384?

Gerv

[Arkadiusz Ławniczak]

Hi

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). All popular web browsers support all three P-256, P-384 and P521 curves. The P-521 certificates are imported correctly even to the old iPhone 5S (iOS 10.3.2) or to the Samsung SM-T325 (Android 4.4.2). If the software does not support elliptic curves, it does not support them all - all or none.

Also, when we consider NIST Special Publication 800-57 Part 1, Revision 4. Recommendation for Key Management, P. 53, Table 2: Comparable strengths (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf)
we can see the strengths of algorithms given as security bits. It clearly shows that algorithms based on P512 + curves represent 256 bits of security while curve 384 represents 192 bits.
>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.


PS.
Some example from Adobe world. The new AATL Technical Requirements (June 2017) states that:

>RCA8 [...]For Elliptic Curve signature technology, a key length of 256-bit or higher is required for RCA certificates.
>A key length of 384-bit or higher is required for RCA certificates that are issued on or after 1 July 2017. [...]

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.


--
Arkadiusz Ławniczak

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assec...@lists.mozilla.org] On Behalf Of Arkadiusz Ławniczak via dev-security-policy
Sent: Thursday, June 29, 2017 9:12 AM
To: ry...@sleevi.com; Alex Gaynor
Cc: MozPol; Gervase Markham; Kurt Roeckx
Subject: RE: P-521

Hello all

As CERTUM, we would like to create and submit to Mozilla our two new root CAs. There would be nothing unusual about this but I've found that Mozilla Policy doesn't allow to use algorithm P-521 and that is what we want to use in our root CA.

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

P-256, P-384 and P-521 curves are commonly implemented in all popular cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware cryptographic modules.

But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has limited its policy to only two curves P-256 and P-384.
The reasons for this decision are known only to this agency and Mozilla. It can be assumed that stronger cryptography is currently embarrassing for the NSA, and the safety margin over the operation time is low.

[Gervase Markham]

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

[Alex Gaynor]

On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy <
dev-secur...@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

[Gervase Markham]

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

[Ryan Sleevi]

On Thu, Jul 6, 2017 at 10:46 AM, Gervase Markham via dev-security-policy <
dev-secur...@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 )

[J.C. Jones]

On Tue, Jun 27, 2017 at 1:49 PM, Tom . wrote:

> On 27 June 2017 at 11:44, Alex Gaynor wrote:
> > I'll take the opposite side: let's disallow it before it's use expands
> :-)
>

> But is that what we're talking about? I didn't think the question was
> "Should we remove P-521 code from NSS" it's "Should we permit CAs to
> use P-521?"
>

Note: Forbidding P-521 by policy likely wouldn't prompt us to disable or
remove any code from NSS in any quick fashion; that curve is one of those
exported to WebCrypto, and we'd need to be sure we weren't breaking things
by pulling it from there. Given the low usage of ECDH/ECDSA and the lack
of compatibility in Chrome, probably not, but we'd want to at least check.

-J.C.

[Gervase Markham]

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

[Gervase Markham]

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