Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 25 Apr 2017 13:08:01 +0100

On 18/02/2017 02:31, Dr Stephen Henson wrote:
> 
> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
> certificates too?
> 
> For example could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
> a certificate contain an RSASSA-PSS key?
> 

I can't recall getting a definitive answer to this. IMHO we should make the
requirements clear in the spec otherwise we could get interop issues.

Based on the opinions stated in this thread that would be:

1. When PSS signatures appear certificates, MGF digest and signing digest MUST
match and the salt length must equal the digest length.

2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys MUST
be supported both as server keys and CA keys in certificates.

3. PSS only keys MUST be supported for TLS 1.2 also.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 Apr 2017 09:36:28 -0500

> match and the salt length must equal the digest length.

We have (in section 4.2.3, Signature Algorithms):

   RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
      PSS [RFC3447 <https://tools.ietf.org/html/rfc3447>] with mask generation function 1.  The digest used in
      the mask generation function and the digest being signed are both
      the corresponding hash algorithm as defined in [SHS <https://tools.ietf.org/html/draft-ietf-tls-tls13-19#ref-SHS>].  When used
      in signed TLS handshake messages, the length of the salt MUST be
      equal to the length of the digest output.  This codepoint is also
      defined for use with TLS 1.2.

Is the concern that this is insufficiently clearly indicated as placing requirements on signatures of certificates as opposed to signatures of TLS data structures?

> be supported both as server keys and CA keys in certificates.

Similarly to (1), I believe that it is possible to read the existing
(draft-19) text as making these requirements already, so is the concern
that the text needs to be more clear?

> 3. PSS only keys MUST be supported for TLS 1.2 also.

Section 1.3, "Updates Affecting TLS 1.2" notes:

   [...]
   -  RSASSA-PSS signature schemes are defined in Section 4.2.3
<https://tools.ietf.org/html/draft-ietf-tls-tls13-19#section-4.2.3>.

   An implementation of TLS 1.3 that also supports TLS 1.2 might need to
   include changes to support these changes even when TLS 1.3 is not in
   use.  See the referenced sections for more details.

-Ben

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 25 Apr 2017 15:59:07 +0100

> Is the concern that this is insufficiently clearly indicated as placing requirements on signatures of certificates as opposed to signatures of TLS data structures?

Yes that's my concern. Supporting PSS signatures on certificates is a mandatory
requirement and I think we should be very clear about the parameters we permit.

The above paragraph says nothing about salt length limitations on signatures on
certificates. We could have a situation where one implementation enforces the
salt length to be equal to the digest length (and rejects everything else) and
another will allow any valid length.

> Similarly to (1), I believe that it is possible to read the existing (draft-19)
> text as making these requirements already, so is the concern that the text needs
> to be more clear?
> 

Yes. id-RSASSA-PSS isn't mentioned anywhere in the spec. If we require
implementations to support this I think we should be explicit about it.

We might want to refer to RFC5756/RFC4055 which document the syntax.

Steve.

---

From: [email-masked] (Martin Rex)
Date: Wed, 26 Apr 2017 15:23:57 +0200 (CEST)

Dr Stephen Henson wrote:
>> Is the concern that this is insufficiently clearly indicated as placing
>> requirements on signatures of certificates as opposed to signatures of
>> TLS data structures?
> 
> Yes that's my concern. Supporting PSS signatures on certificates is
> a mandatory requirement and I think we should be very clear about the
> parameters we permit.
> 
> The above paragraph says nothing about salt length limitations on
> signatures on certificates. We could have a situation where one
> implementation enforces the salt length to be equal to the digest length
> (and rejects everything else) and another will allow any valid length.

It has always been a terribly stupid bug that TLS started talking about
signatures on certificates when negotiating TLS protocol properties,
and it resulted in a few painfully broken TLSv1.2 implementations getting
shipped (such as Microsoft Windows7/2008R2 through 8.1/2012R2).

Please ensure that TLSv1.3 is cleaned from bogus references about
requirements on signature algorithms for certificates.

Signatures on certificates are created by CAs, rather than TLS endpoints,
so any implementation that uses TLS protocol parameters (about TLS signature
algorithms) for more than a mere cert selection hint, is actively creating
interop problems while providing *NO* value.  Many TLS peers will have
just one suitable certificate anyway, so not even looking at certificate
signatures will be the easiest to implement, most robust and perfectly secure
behaviour anyway.

The issue with RSA-PSS digital signatures is that they were defined
with additional (unnecessary) parameters that are encoded (=hidden) in the
ASN.1 AlgorithmIdentifier, and that are therefore unspecified when
RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1
AlgorithmIdentifier.

The additional, unnecessary parameters are "saltLen" and
"MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction
(mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash).

In theory there is another additional, unnecessary parameter "TrailerField",
which appears in the ASN.1 AlgorithmIdentifier parameter list (and in the
XMLdsig encoding for RSA-PSS), but PKCS#1 v2.1 (rfc3447) essentially
hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc.

The definition of "implied" RSA-PSS parameters applies only to the
"digitally-signed" signature blobs using inside the TLS protocol
because these do not come with an ASN.1 AlgorithmIdentifier tag.
The implied RSA-PSS paramters for TLS' digitally-signed are unrelated
to RSA-PSS signatures on certificates (certificates come with explicit
RSA-PSS parameters encoded in an ASN.1 AlgorithmIdentifer):

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

The original RSA-PSS AlgorithmIdentifer specification also defines
a hierarchical policy concept, that is supposed to limit the kinds
of signatures that can be created (verified) with a so-tagged public
RSA key, and this policy is supposed to work/apply from the RootCA cert
*downwards* to the leaf / end-entity cert.

It seems silly trying to apply implied RSA-PSS parameter selections
from the digitally-signed TLS protocol transform to the signature
on the TLS end-entity cert (or worse, even to certs up the cert chain),
because that would be the wrong/invalid direction.

What should be spelled out, whether and how any RSA-PSS policy in the
subjectPublicKeyInfo AlgorithmIdentifier of the end-entity certificate
interacts with implied RSA-PSS parameters used by the TLS digitally-signed
transform.  In any case, the decision whether to accept a certificate
should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 26 Apr 2017 16:41:40 +0300

> signatures will be the easiest to implement, most robust and perfectly secure

What my implementation does with certificate signatures:
- There actually are signature algorithms with no known TLS code, e.g.
  ECDSA-SHA3 signatures. These are known but can not be advertised.
- The built-in server-side certificate selection code never selects
  certificate containing algorithm client didn't advertise.
- The server side certificate chain checking interlocks on unknown
  signature algorithms, but not unadvertised signature algorithms. So
  custom certificate selector can overrule the client advertisment, but
  not known algorithm check.
- On client side, all known algorithms (other than PKCS#1/SHA-1, which
  is treated specially) are treated as valid for certificates. Advertised
  or not. All others are just ignored (which violates a MUST in spec)
  and path building never builds through those..
- Regarding RSA-PSS, only the 3 variants that TLS defines are supported).

> RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1

TLS 1.3 specifies what values those parameters have for various
SignatureSchemes.
 
> (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash).

Also specified.

> hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc.

So this also counts as specified.

> *downwards* to the leaf / end-entity cert.

I don't think it appiles that way, only per-key.

ExtendedKeyUsage is *not* supposed to be hierarchial, but doesn't
prevent many libraries from handling it that way.

> because that would be the wrong/invalid direction.

The SignatureScheme selections only mean those schemes are supported,
not that other RSA-PSS schemes can't be supported in CA signatures
(however, there is no way to advertise those).

> should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender.

AFAIK, the only place there is any impiled interaction is when the end-
entity key is RSA-PSS-only. And there the rules are usual matching rules
versus the key.

-Ilari

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 26 Apr 2017 15:10:27 +0100

>> (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash).

For TLS message signatures yes.

For signatures on certificates I think it is far less clear. For salt lengths
the spec says:

"When used in signed TLS handshake messages, the length of the salt MUST be
 equal to the length of the digest output."

It says nothing about salt length restrictions (if any) on certificates.

Steve.