Interested in reviving PSS support in NSS

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Interested in reviving PSS support in NSS

Hanno Böck-4
Hi,

A couple of years ago I participated in a summer of code project for
NSS to create an implementation of the RSA-PSS signature scheme für
X.509 signatures.

Unfortunately the code never got fully merged. Right now the state is
that code for the basic functions exists in freebl, but all upper layer
code is not merged. I think if I remember correctly the code currently
in freebl will also not work in some corner cases (keys mod 8 != 0).

The bugtracker entry is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=158750

I would be motivated to take up that work again if someone from the
NSS team would be willig to work on merging the code. I'd be interested
in this because I want to make a proposal to get PSS support into TLS
1.3 and it would certainly help if I could say that all major TLS
libraries support it already.

cu,
--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Interested in reviving PSS support in NSS

Ryan Sleevi
On Sun, February 15, 2015 3:07 pm, Hanno Böck wrote:
>  Unfortunately the code never got fully merged. Right now the state is
>  that code for the basic functions exists in freebl, but all upper layer
>  code is not merged. I think if I remember correctly the code currently
>  in freebl will also not work in some corner cases (keys mod 8 != 0).

This is true for all of the RSA code in NSS (not handling non-mod 8 keys).
This is also fairly consistent across several cryptographic libraries.

I refactored this code to move it from softoken (the PKCS#11 shim) into
freebl (the crypto primitives), where unit tests were also added (to
bltest). This was tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=836019

There were also issues where it wasn't exposed (at the PKCS#11 layer) /
wasn't validating parameters correctly, but those should be fixed.

>  The bugtracker entry is here:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=158750
>
>  I would be motivated to take up that work again if someone from the
>  NSS team would be willig to work on merging the code. I'd be interested
>  in this because I want to make a proposal to get PSS support into TLS
>  1.3 and it would certainly help if I could say that all major TLS
>  libraries support it already.

I'm quite mixed on this as the motivation (PSS in TLS), but I think the
state of implementing and exposing PSS through the appropriate layers
(except for TLS) is worth doing.

Here's the current status of PSS support:
What works:
- It's implemented (and tested) in freebl/ with bltests
- It's implemented (but not tested) in softoken/ as a PKCS#11 mechanism
for C_Sign/C_Verify

What doesn't:
- There's no way to reach it from PK11_Sign, due to the fact that
PK11_Sign doesn't take a CK_MECHANISM_TYPE/SECITEM* param pair (like
PK11_Encrypt), and thus you can't supply the CK_RSA_PKCS_PSS_PARAMS that
you might have
- PK11_MapSignKeyType is used rather extensively, and it maps the
SECKEYPrivateKey KeyType incorrectly (rsaPssKey should map to PSS, but
doesn't)
- The more general issue of SECKEYPublicKey/SECKEYPrivateKey not handling
the PSS appropriately (nearly every switch on KeyType will handle this
wrong, for example; further, it's become enshrined in plenty of downstream
code as to how to handle PSS keys here)
- The SGNContext*/VFYContext* interface is entirely borked for PSS.
  - It assumes all the parameters can be expressed via a SECOidTag. That
is, it's missing hash alg, mgf alg, salt length (e.g. the
RSASSA-PSS-params construction)
  - SEC_GetSignatureAlgorithmOidTag is borked for PSS
  - SECOID_GetAlgorithmTag is borked for PSS
- CERT_VerifySignedData doesn't handle PSS (e.g. policy checking flags)


Of course, I'm ignoring all the issues with the nightmare that is the SPKI
for PSS/OAEP and those behaviours. If you're expecting CAs to issue such
certificates, I would call it extremely unlikely.

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Interested in reviving PSS support in NSS

Brian Smith-19
In reply to this post by Hanno Böck-4
[+antoine]

Hanno Böck <[hidden email]> wrote:
> Unfortunately the code never got fully merged. Right now the state is
> that code for the basic functions exists in freebl, but all upper layer
> code is not merged.

There are multiple "upper layers" and, depending on your goals, some
should be prioritized higher than others.

> I think if I remember correctly the code currently
> in freebl will also not work in some corner cases (keys mod 8 != 0).

IIUC, this is not urgent to support and may not be worth supporting at
all. IIRC, there are lots of places in NSS and mozilla::pkix that
explicitly reject keys and signatures that are not multiples of 8
bits.

> The bugtracker entry is here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=158750

That bug is too big and messy to make sense of at this point. Also,
some of the patches that haven't been checked in yet should be split
up. I suggest that you proceed as follows:

1. Split 000a-pss-verification-v15.diff into two patches: One part
that adds the pk11wrap functionality, and a separate part that adds
the cryptohi functionality. Put each new patch in its own new NSS bug.

2. Move 0009-add-pk11-mgfmap-v3.diff, 000b-pss-sign-v15.diff, and
000c-tests-v2.diff to a new bug.

3. Move 0012-fix-pss-verification-for-uncommon-keysizes-v5.diff to a
new bug, which will have low priority.

4. Close the existing bug as RESOLVED FIXED.

Even with all the above patches landed, Firefox and other Gecko-based
applications will not accept PSS signatures for certificates. Of the
above patches, only the patch to add PK11_VerifyWithSigAlg is relevant
to Gecko. New patches for mozilla::pkix and for its test suite, which
basically duplicate all the work in the rest of the patches mentioned
above, would be needed. But...

> I want to make a proposal to get PSS support into TLS
> 1.3 and it would certainly help if I could say that all major TLS
> libraries support it already.

First somebody needs to create a reasonable specification detailing
exactly which subset of the PSS specification should be supported for
TLS. The current PSS specification allows *way* too much flexibility
and also has terrible defaults. I believe Antoine and his team have a
good idea of what a reasonable subset of PSS would look like. I
recommend working with him to develop such a spec. Without such a
spec, I wouldn't support adding PSS support to mozilla::pkix.

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Interested in reviving PSS support in NSS

Brian Smith-19
In reply to this post by Ryan Sleevi
Ryan Sleevi <[hidden email]> wrote:
>   - It assumes all the parameters can be expressed via a SECOidTag. That
> is, it's missing hash alg, mgf alg, salt length (e.g. the
> RSASSA-PSS-params construction)

I believe there are only a small number of (hashAlgorithm, mgf alg,
salt length) combinations that need to be supported, namely these two:

    (sha256, mgf1-SHA256, 32 bytes)
    (sha384, mgf1-SHA384, 48 bytes)

I think that in NSS, these combinations can be identified internally
with some new OID, perhaps in the Netscape OID tree.

Note that the PSS RFC says that SHA-1 is the default for everything.
By not supporting SHA-1 at all, we avoid having to deal with any
implicit encodings of the various parameters. The PSS RFC also says
that SHA-1 is mandatory, but that silliness is just an invitation for
somebody to get their name as an author of a new, reasonable, RFC.

Thoughts?

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Interested in reviving PSS support in NSS

Antoine Delignat-Lavaud
In reply to this post by Brian Smith-19
Le 2/16/2015 6:15 AM, Brian Smith a écrit :

>> I want to make a proposal to get PSS support into TLS
>> 1.3 and it would certainly help if I could say that all major TLS
>> libraries support it already.
> First somebody needs to create a reasonable specification detailing
> exactly which subset of the PSS specification should be supported for
> TLS. The current PSS specification allows *way* too much flexibility
> and also has terrible defaults. I believe Antoine and his team have a
> good idea of what a reasonable subset of PSS would look like. I
> recommend working with him to develop such a spec. Without such a
> spec, I wouldn't support adding PSS support to mozilla::pkix.
We have thought about how to get PSS into TLS 1.3 (both for
CertificateVerify signatures and within certificate chains). I am not
inclined to believe (after bringing up the issue privately with ekr)
that it is possible to make PSS the default RSA algorithm in TLS.
Instead, I have suggested [1] to use the (now mandatory)
signature_algorithms extension to negotiate the algorithm of the
CertificateVerify signatures instead of making it part of the cipher
suite name. In this spirit, it seems perfectly adequate to define new
OIDs for the PSS(sha256, mgf-sha256, 32) and PSS(sha384, mgf-sha384, 48)
algorithms as rsa-pss/sha256 and rsa-pss/sha384 that certification
authorities could use to sign certificates (this would unify the
semantics of signature algorithm support in TLS and PKIX, and make it
independent of the key-exchange related cipher suite negotiation).

Even though ekr appeared willing to implement this change when we
discussed it, the TLS working group has mixed feelings about this idea;
hence, I haven't tried pushing it further. If there is some willingness
from Mozilla and/or Google to back it up, I would be happy to assist
with the writing of a specification for it.

As an alternative, it would also be possible to keep the current RSA
signatures for CertificateVerify messages and only introduce support for
PSS in certificates. However, the CA system evolves slowly (many CAs use
HSM that either don't support PKCS#1v2.1 or won't accept mgf-sha256) and
without use in TLS itself I have doubt that PSS will see any adoption.

Best,

Antoine

[1] https://www.ietf.org/mail-archive/web/tls/current/msg14859.html


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Interested in reviving PSS support in NSS

Hanno Böck-4
In reply to this post by Brian Smith-19
On Sun, 15 Feb 2015 21:34:04 -0800
Brian Smith <[hidden email]> wrote:

> I believe there are only a small number of (hashAlgorithm, mgf alg,
> salt length) combinations that need to be supported, namely these two:
[...]
> The PSS RFC also says
> that SHA-1 is mandatory, but that silliness is just an invitation for
> somebody to get their name as an author of a new, reasonable, RFC.
>
> Thoughts?

Having new oids with sane pre-defined parameters would vastly simplify
things. Back when I wrote that code I thought changing the standard is
harder than implementing the non-optimal spec, but I might've been
wrong.
Such an RFC could also just declare that keys not divisable by 8 are
disallowed and by that fix that problem as well.

I don't really know what channels I'd have to go through to pursue
such a preset-OID. Can an OID be defined by an RFC? How does the
interaction between the OID registration and RFCs work? Is this
something the CFRG would do or some other entity in the IETF?


--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Interested in reviving PSS support in NSS

Hubert Kario
On Monday 16 February 2015 18:40:59 Hanno Böck wrote:

> I don't really know what channels I'd have to go through to pursue
> such a preset-OID. Can an OID be defined by an RFC? How does the
> interaction between the OID registration and RFCs work? Is this
> something the CFRG would do or some other entity in the IETF?

OIDs in private organisation trees are defined by the organisation, so if
Mozilla just publishes a document stating that such and such numbers mean this
and this it's practically defined no need for involvement of any external
entities to define it.

But I don't think we need or even want OID in the ClientKeyExchange or
ServerKeyExchange...
There's just a need to define a new SignatureAlgorithm (e.g. 4) that would say
rsa-pss. Then the RFC would bind specific parameter sizes to given hashes.

The OID would just be an implementation detail in NSS, though it could in
theory be reused for X.509.
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Interested in reviving PSS support in NSS

Brian Smith-19
In reply to this post by Hanno Böck-4
Hanno Böck <[hidden email]> wrote:
> Brian Smith <[hidden email]> wrote:
> Having new oids with sane pre-defined parameters would vastly simplify
> things. Back when I wrote that code I thought changing the standard is
> harder than implementing the non-optimal spec, but I might've been
> wrong.

To clarify: I'm suggesting that you parse the raw RSA-PSS parameters
from the signature and from the public key into a tuple
(hashAlgorithm, maskGenAlgorithm, saltLength) like you normally would.
Then, for certain tuples, define OIDs that are only used internally in
NSS to identify (using the SECOidTag representation) that combination.
These OIDs would never be seen on the wire.

This would mean, in addition, that instead of having an rsaPSSKey
type, that we'd have an rsa_PSS_SHA256_MGF1SHA256_32_key type and an
rsa_PSS_SHA384_MGF1SHA384_48_key type.

> Such an RFC could also just declare that keys not divisable by 8 are
> disallowed and by that fix that problem as well.

Sure, but in practice it isn't a problem. Everybody's been doing the
same for RSA-PKCS#1.5 forever already.

> I don't really know what channels I'd have to go through to pursue
> such a preset-OID. Can an OID be defined by an RFC? How does the
> interaction between the OID registration and RFCs work? Is this
> something the CFRG would do or some other entity in the IETF?

As I mentioned above, you don't need to define these OIDs in an RFC,
since they would exist only for the purpose of fitting into NSS's API.

The purpose of the RFC would be to nail down which (hashAlgorithm,
maskGenAlgorithm, saltLength) are allowed and mandatory to support for
certificates.

Note that Microsoft's documentation hints that they implemented
RSASSA-PSS-SHA256 using the tuple (SHA256, MGF1-SHA1, 20) instead of
(SHA256, MGF1-SHA256, 32) like I would expect. Perhaps their
RSASSA-PSS-SHA384 is (SHA384, MGF1-SHA1, 20) too? If so, is it more
important to interop with them than to have all the parameters match
in the intuitive way?

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto