1609189 - When unlocking NSS internal key token, automatically upgrade to a higher iteration count

Status: NEW

(NSS :: Libraries, enhancement, P3)

Description

[Kai Engert [:KaiE:]]

It's unclear if this bug should be implemented at the NSS library level, or at the Mozilla PSM level.

In the past, NSS always used iteration count 1 for PBE using the master password.

We recently increased the default to use a higher number of iterations. However, that higher number is used only when enabling the master password, or when changing the master password.

It has been suggested to automatically upgrade to the configured iteration count at the time we unlock the NSS database. In other words, when unlocking, we should check for the iteration count currently used by the database. If it's lower than the current runtime default, then run through the password change procedure, while still using the same master password.

NSS could potentially do that, because it has access to all the internal information.

Are the NSS developers willing to allow such an automatic conversion, or are there any concerns about that approach?

Should there be concerns, we'd have to implement that at the PSM level. However, we'd require a new API that allows the application to query the currently used iteration count of the token, and also the currently configured default. If current is lower than default, then PSM could trigger the password change procedure.

Comment 1

[Kai Engert [:KaiE:]]

Are the NSS developers willing to allow such an automatic conversion, or are there any concerns about that approach?

Comment 2

[Robert Relyea]

It's not something I would prioritize. I think I would be against trying to look at the actual iteration count of the database and trying to adjust that, but I may be OK with some notion of updating if a 'security level meta tag' isn't present. If this were an NSS change, I would perfer the meta data tag approach.

There are a couple of issues that would have to be addressed:
1) what happens if the iteration code is adjusted with the environment variable, or some other mechanism.
2) what about AES_CBC versus DES3.
3) what about future increases to the database security.
4) since each entry can be updated separately, it can be quite tricky to guarrentee a particular level of security in the database as update time.
5) this can only happen when you open a database r/w and you also authenticate.

If the application wants to do this, we would need to surface some information about the underlying database to the application (like min and max iteration count, encryption oid, etc. probably through the same interface that we would surface things like update state). In that case the application could decide if it wants to reencrypt the database (which it already has the ability to do with the change password call).

bob

Comment 3

[J.C. Jones [:jcj] (he/they)]

Generally, I think this belongs in NSS rather than PSM.

I'd prefer to use some metadata tag than the actual iteration count, too. Something that when we update a significant default, and when we feel comfortable with it, if profile security level is < current security level, then do a migration.

I think both the default iteration count and the AES_CBC change would be independently worthy of such a version bump. Changing from CBC to KeyWrap, however, maybe not worth it, but we could always give it some time and change it later.

If there's an environment variable setting the iteration count, then we'd still follow that during a security level bump. If that makes no actual change -- because NSS_MAX_MP_PBE_ITERATION_COUNT == NSS_MIN_MP_PBE_ITERATION_COUNT == the actual count in use, I think that's OK -- the env variable should be the override, after all.