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

[[e-mail] (Martin Rex)]

Dr Stephen Henson wrote:
> On 25/04/2017 15:36, Benjamin Kaduk wrote:
>> 
>>    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?
> 
> 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