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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, 2017-09-12 at 14:41 +0100, Dr Stephen Henson wrote:
> On 11/09/2017 19:42, Eric Rescorla wrote:
> > Ugh.
> > 
> > Generally, the idea with signature schemes is that they are
> > supposed to reflect
> > both the capabilities of your TLS stack and the capabilities of
> > your PKI
> > verifier [0]. So, yes, if you advertise this it is supposed to
> > work. So, ideally
> > we would just say that it's as Ilari says in his followup.
> > 
> > It seems like there are really two choices:
> > 
> > 1. Only advertise algorithm X if you support algorithm X in both
> > places
> > 2. Invent a new extension whose semantics are "if present, this
> > tells you what
> > the PKI validator accepts, otherwise look at signature schemes"
> > 
> > I hate to be suggesting #2 at this stage in the process, but maybe
> > it's right
> > anyway...
> > 
> 
> It's rather more than just certificate signatures.
> 
> The problem here is that there is no way to indicate an
> implementation supports
> rsaEncryption keys but not RSASSA-PSS keys and the current draft
> requires that
> implementations support both AFAICS.
> 
> RSASSA-PSS keys are pretty rare at the moment. There are some
> complications
> involved with supporting them not present with other key types: more
> complex parameter sets and key restrictions for example.

Right, that is indeed a significant complexity, and unfortunately the
RSASSA-PSS parameters in certificates/keys are quite uniquely in PKIX.
However, these are optional parameters, and one could support RSA-PSS
keys without such parameters/restrictions relatively easily. Moreover,
keys without paramters, are the keys which are typically expected to be
used by TLS. 

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.

>  Implementors might feel
> (despite what the draft says) that the added complexity is not
> justified because no one will ever want to use RSASSA-PSS keys.

If an implementation does not support RSASSA-PSS-only keys, it means it
will (as a server) not be able to use separate keys for RSASSA-PSS and
RSA PKCS#1 v1.5 operations, right? That's quite a fundamental
limitation and if it exists in popular implementations it makes the TLS
1.3 move to RSASSA-PSS quite questionable. It may be better to support
RSA PKCS#1 v1.5 in TLS1.3 alongside RSASSA-PSS (for the implementations
that chose to opt-in), rather than forcing a move to RSASSA-PSS without
providing any of the benefits of using it. 

regards,
Nikos