Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

[Hubert Kario <[e-mail]>]

On Tuesday, 12 September 2017 17:42:31 CEST Dr Stephen Henson wrote:
> On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote:
> > That is, because a TLS server would typically sign with whatever
> > algorithm the client supports and would very rarely be interested to
> > utilize the security advantages of including the parameters (which,
> > advantages, are quite unclear even to a crypto expert). Otherwise, a
> > certificate restricted to SHA-384 and 48-bytes of salt, will not be
> > able to serve a client which only supports RSASSA-PSS with SHA-256.
> > 
> > As such, it would make sense for TLS 1.3 to recommend no parameters for
> > such RSASSA-PSS certificates, to ease their deployment.
> 
> Well restrictions in CA keys would be handled by the PKI verifier: if there
> is a violation the chain should be rejected and it's a problem with the
> chain itself and an error by the CA that issued it. A different case is
> where the restrictions are legal from a PKIX standpoint but not allowed by
> TLS 1.3, though again it's a CA error issuing such a chain for TLS 1.3 use.
> 
> A restriction on the EE key isn't quite the same. There are two cases.
> 
> One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1
> digest doesn't match signing digest or minimum salt length exceeds digest
> length). In this case a server should never present the chain or if it does
> a client would justifiably reject it and abort the handshake. Again this is
> an error by the issuing authority which should be corrected.
> 
> The second case is that the parameter restriction is permitted by TLS 1.3
> and this limits the digest which the key can sign with. Say the restriction
> is SHA384 and the client only supports rsa_pss_sha256. The server might
> then use to a different PSS key (and certificate chain) that supports
> rsa_pss_sha256 or fall back to an RSA key to use rsa_pss_sha256. Again if a
> client sees a TLS message signed with parameters that violate the
> restrictions it could (with some justification) abort the handshake.
> 
> This could get pretty messy: it requires a logic not used in any other
> algorithm. I'd be more than happy to have an outright prohibition on EE PSS
> key parameter restrictions in TLS 1.3 so implementers don't have to bother
> with this.

what about hardware tokens that support only specific hashes or signatures?
(I've seen ones that can do only RSA with SHA256 and SHA-1, but not SHA-384 or 
SHA-512) Isn't it basically the same code path (though the limitation does 
come from slightly different place).
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic