1601801 - RSA PSS SPKI handling in TLS loses parameters

Status: NEW

(NSS :: Libraries, task, P3)

Description

[Martin Thomson [:mt:]]

NSS uses SECKEY_* functions to manage keys. Unfortunately, these functions erase RSA PSS parameters. This results in our TLS functions receiving keys that are configured for a particular MGF, but then using them for another variation of that function. For instance, a PSS key with SHA-256 parameters can be used with SHA-384.

There are two potential remedies for this: changing SECKEY_* functions to preserve the key parameters might require some intrusive changes and that might touch on ABI compatibility; preserving the extra parameters in TLS code is hacky, but it is consistent with other uses of PSS in the code and would not be so intrusive.

Comment 1

[Ryan Sleevi]

There was some discussion of this back in 2015, in https://www.mail-archive.com/[e-mail]/msg12146.html (and follow-ups and related)

The question was largely around parameter fidelity, since PSS at the SPKI layer is... flexible. Given that TLS has constrained the set of parameters that can be used (IIRC), it may be possible to revisit the SECOidTag approach, which would avoid the ABI issues. That is, if the SPKI parameters can be coerced into a sensible SECOidTag (or vice-versa), it might work.

Of course, as you note, an alternative might be to do this at the TLS layer, and that might be easier.

Just sharing some past context since the SECKEY_* functions with PSS were a known pain-point :)

Comment 2

[Martin Thomson [:mt:]]

Yes, I didn't want to put this in the initial comments here, but I've concluded that no matter how good PSS is, the failure of the IETF to nail down parameters has caused an inordinate amount of pain. If I have any say in future standardization of primitives, they will not replicate this mess.