1172128 - Undo the freebl/softoken RSA/DH/DSA minimum key size increases in bug 1138554

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Wan-Teh Chang]

Attachment: Proposed patch

In bug 1138554 comment 84, Ryan reported that the fix
for bug 1138554 breaks an NSS-based application that
needs to generate or import an RSA/DH/DSA key shorter
than 1023 bits. The proposed patch does two things:

1. It reverts the freebl/softoken RSA, DH, and DSA
minimum key sizes to the original values in NSS 3.19.
(I chose to simply revert because nobody has suggested
what the appropriate freebl/softoken minimum key sizes
should be.)

2. It adds three SSL-specific macros for the minimum
server key sizes accepted by the clients.

We should treat this bug as a regression with urgency.

Comment 1

[Robert Relyea]

Comment on attachment 8616195 [details] [diff] [review]
Proposed patch

r+ rrelyea.

I have not clobbered the review request for martin because I'm still interested in martin's feedback.

bob

Comment 2

[Martin Thomson [:mt:]]

Comment on attachment 8616195 [details] [diff] [review]
Proposed patch

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

Sorry for missing this; I've been out of town.

Comment 3

[Martin Thomson [:mt:]]

I don't mind either way here.  Minimums will always be set low for compatibility reasons, and that is lower than I think ideal.  I suspect that the right thing to do is make the minimum values for libssl configurable.  Firefox enforces its own limits for that reason.

Note that this will affect some of the changes that were landed in Firefox.  cc :keeler.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

If you can land this and request uplift by tomorrow evening, this can make it into 39 Beta 5. There is one more week to land changes for Beta 7 (our last of this 4 week short cycle.)

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

needinfoing mt and rbarnes since it looks like Wan-Teh may be on vacation for the next couple of weeks.

Comment 6

[Martin Thomson [:mt:]]

This is unlikely to make the next beta.  And it doesn't need to.

The changes here require backouts for the extra fixes added in bug 1166031 if it lands.  Since this doesn't affect Firefox, other than by messing with our tests, I'm going to recommend that we wait for the normal release cycle to clean this up.

Comment 7

[Wan-Teh Chang]

Martin: please check in this patch for me. Thanks.

Also, we should release an NSS release soon to address this bug.
The minimum sizes for freebl/softoken can still be increased.
Since nobody came forward with suggestions, I decided to go back
to the original minimum sizes so that we can make the important
changes quickly.

Comment 8

[Wan-Teh Chang]

(In reply to Martin Thomson [:mt:] from comment #6)
> 
> The changes here require backouts for the extra fixes added in bug 1166031
> if it lands.

Martin: which fixes need to be backed out? None of the patches in bug 1166031
seem to depend on the minimum key sizes of freebl/softoken or lib/cryptohi.

Comment 9

[Martin Thomson [:mt:]]

I think that we would need to backout attachment 8613120 [details] [diff] [review].  The others look OK.

Do you want me to apply a 3.19.2 beta1 tag so that we can get this into mozilla-central?

Comment 10

[Martin Thomson [:mt:]]

https://hg.mozilla.org/projects/nss/rev/2b29dfe134a5

I got the attribution wrong here, but it's there.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Oh, got it. I misunderstood an email from rbarnes to mean this should land. Thanks martin and wan-teh.

Comment 12

[Wan-Teh Chang]

(In reply to Martin Thomson [:mt:] from comment #9)
> I think that we would need to backout attachment 8613120 [details] [diff] [review].

Could you explain why? I didn't revert any of the SECKEY_BigIntegerBitLength
changes.

> Do you want me to apply a 3.19.2 beta1 tag so that we can get this into
> mozilla-central?

Yes, please. Thank you very much for your help.

Comment 13

[Martin Thomson [:mt:]]

Actually I was wrong about the attachment, David made the numbers bigger, which should be OK.

Comment 14

[Kai Engert (:KaiE:)]

(In reply to Martin Thomson [:mt:] from comment #10)
> https://hg.mozilla.org/projects/nss/rev/2b29dfe134a5
> 
> I got the attribution wrong here, but it's there.

marking fixed in NSS

Comment 15

[Kai Engert (:KaiE:)]

Liz, FYI: We consider NSS a separate product, with its own release cycles. The NSS library is consumed by multiple parties, in addition to Firefox. Linux distributions consume NSS and Firefox separately. For that reason, Firefox release versions must always use release version of NSS. Although this bug marks the issue as fixed in NSS, tracking the fix for Firefox is done separately. I've filed 1174102 to track upgrading Firefox to the NSS release with this fix.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Thanks Kai. Any explanations are super useful to me and I appreciate them.   I know it is a separate entity but I think we do decide how quickly or how hard we can uplift NSS updates. For example, we could choose to do a point release on the current version of Firefox (38.0.5) but will likely not do that.   (Which is what we would have to do if the Firefox release version needed to use the release version of NSS)