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

[Ilari Liusvaara <[e-mail]>]

On Wed, Apr 26, 2017 at 03:23:57PM +0200, Martin Rex wrote:
> 
> 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.

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).


> 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.

TLS 1.3 specifies what values those parameters have for various
SignatureSchemes.
 
> The additional, unnecessary parameters are "saltLen" and
> "MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction
> (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash).

Also specified.

> 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.

So this also counts as specified.

> 
> 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.

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.

> 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.

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).

> 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.

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