495836 - Increase key sizes of the keygen tag

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement, P2)

Description

[Eddy Nigg (StartCom)]

As per NIST and other recommendations, RSA 1024 bit keys should not be used anymore beyond 31st of December 2010. We are approaching this target date and the keygen tag should use bigger key sizes.

As per https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag for RSA keys the user is given a choice between "high" strength (2048 bits) and "medium" strength (1024 bits).

We should double those sizes to 2048, respectively 4096 bit.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Relevant PSM code is at 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsKeygenHandler.cpp&rev=1.49&mark=341,343#339

Comment 2

[Eddy Nigg (StartCom)]

Attachment: Increased key size for KEYGEN tag

Kai, please confirm the bug and approve the patch. For additional information, Microsoft makes it a requirement to use RSA key sizes equal or bigger than 2048 bit. Existing 1024 bit certificates should expire by 31st of December 2010. I'll also higher the priority for this bug, since otherwise the KEYGEN tag can't be used by CAs anymore.

Comment 3

[Eddy Nigg (StartCom)]

As indicated in the comment above, as per Tom Albertson (Microsoft) and http://technet.microsoft.com/en-us/library/cc751157.aspx#EHAA section 10, 2048 bit key sizes will be disallowed for CAs participating at the MS root program. Effectively the KEYGEN tag couldn't be used since per https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag for RSA keys, the KEYPARAMS parameter is not used (ignored if present).

Comment 4

[Eddy Nigg (StartCom)]

Test build I made creates some real fat 4096 RSA keys...it even takes a while until FF spits it out. :-)

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

This is an enhancement request.

Comment 6

[Eddy Nigg (StartCom)]

Just to be sure about the severity here (and your change to enhancement). If CA's can't use KEYGEN anymore due to requirements I'd view this as major, not enhancement.

Comment 7

[Daniel Veditz [:dveditz]]

Not "blocking" the stable release branches, but after review and "trunk baking" we may approve the patches. However it's premature to request approval now.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> I'd view this as major, not enhancement.

It may be a "major enhancement", but unfortunately we've only got one level of enhancement severity. Feature requests for bugzilla call for splitting bug/enhancement state from importance.

Comment 9

[Eddy Nigg (StartCom)]

Attachment: Increased key size for KEYGEN tag

This patch corrects also ECC mapping according to the new RSA key sizes presented in the UI selector.

Comment 10

[Kai Engert (:KaiE:)]

Comment on attachment 381420 [details] [diff] [review]
Increased key size for KEYGEN tag

r- because any such change of behaviour would nowadays have to come with some automated tests to make sure nothing breaks

Comment 11

[Michael Tänzer]

This issue has been open since almost 5 years, in the mean time 1024 bit RSA was banned completely and even 2048 bit is slowly bein phased out, the only thing missing is an automated test. I would write it myself but I'm not used to your testing framework. Could someone please take care of this?

Comment 12

[winpackjason]

Why isn't it supported yet? Is there any vested interest not to create 4096-bit RSA keys?

I demand 4096-bit keys, or I will otherwise stop using Firefox and use Edge or Internet Explorer which HAS support for 4096-bit keys.

This bug report has been open for more than 6 years!!! For goodness sake!

Comment 13

[Robert Relyea]

sigh, the keygen tag is the ugly step child of the W3C world. It seems the browsers don't want to support it. Chrome is talking about ripping it out altogether.

Comment 14

[Andi]

The KEYGEN tag is now part of HTML5, no? So it really would be nice to have more keysize options in the most secure browser on the net...

Comment 15

[Christoph Anton Mitterer]

One could really come to conclude, that people are kept from creating sane key lengths by (malicious) intention...

Looking at e.g. the ECRYPT II recommendations (http://www.keylength.com/en/3/) the currently supported sizes are completely inadequate.

Comment 16

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Comment on attachment 381420 [details] [diff] [review]
Increased key size for KEYGEN tag

Review of attachment 381420 [details] [diff] [review]:
-----------------------------------------------------------------

It seems like the only way this will get fixed is if a non-employee contributor writes a patch. Ideally an automated test would be written, but it's unreasonable to expect any non-employee contributor to be able to ever write such a test. Below are some hints for how to improve the existing patch in this bug. I'm not sure if addressing those issues are enough to get a change committed to Firefox.

::: mozilla/security/manager/ssl/src/nsKeygenHandler.cpp.keygen
@@ +338,4 @@
>  
>    // Init possible key size choices.
>    nssComponent->GetPIPNSSBundleString("HighGrade", mSECKeySizeChoiceList[0].name);
> +  mSECKeySizeChoiceList[0].size = 4096;

There are a variety of reasons to think that people would prefer RSA 3072 over RSA 4096 if they aren't happy with RSA 2048, so I recommend using 3072 here instead.

@@ +617,1 @@
>               * we pick one of secp384r1, secp256r1 or secp192r1

Remove all references and uses to the secp192r1 curve and any curves that aren't P-256 and P-384.

@@ +632,3 @@
>                   * equivalent security.
>                   */
>                  switch (keysize) {

This should be:

// NSA Suite B recommends RSA 3072 as an alternative to
// P-384, so use that equivalence in the absence of any
// clearly better alternative.
const char *curve_name = (keysize < 3072 - 8) ? "secp256r1" : ""secp384r1";

Comment 17

[Christoph Anton Mitterer]

While I still doubt that Mozilla will merge such patch,... it would perhaps be better if it's user configurable.

Best would be, if the user can simply select the size instead of being given the completely ambiguous Medium/High drop-down, but that would probably require more changes.

Maybe an alternative would be, that one makes the size of Medium/High configurable via some about:config setting.

Of course I'd still recommend of enforcing a minimum value, IMHO not less than 2048... and a maximum value if FF's crypto code is so bad that it cannot deal with "arbitrary" key sizes (of course there is a practical limit, as creating such extremely large keys would take forever, but from e.g. gpg we know that e.g. 16k keys would still work in acceptable times).

Though I'm a bit unsure what should happen when the user would configure a value that is outside the hard coded boundaries, especially the upper one.
Simply reducing the keysize and giving the user a smaller key than what he thinks he should get is a bad idea, so maybe one could just fail then.

Comment 19

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

We are not allocating resources to improving keygen.