Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Benjamin Kaduk <[e-mail]>]

On Tue, May 29, 2018 at 01:26:27PM -0700, Andrey Jivsov wrote:
> On 05/29/2018 01:07 PM, David Benjamin wrote:
> > I'm not sure I follow this. So, in this scenario, you are the client.
> > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> > 1.3, and this is fine. You are able to verify RSA-PSS signatures from
> > the server at TLS 1.3.
> > 
> > At the same time, you still talk to some TLS 1.2 servers, so you may get
> > a response from them. As TLS 1.2 and TLS 1.3 use the same signature
> > algorithms negotiation, that same ClientHello obligates your client
> > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures
> > from TLS 1.2. But this causes troubles somehow.
> > 
> > I'm confused how a client would have an RSA-PSS function available at
> > one version, but not the other. Or am I misunderstanding your situation?
> 
> There is a need to upgrade TLS 1.2 stack, just because one can now
> negotiate TLS 1.3.
> 
> Does this "upgrade" to TLS 1.2 extends to client authentication? Then
> this adds more work.

In short: no.  CertificateRequest/CertificateVerify have a separate signature+hash
negotiation from the initial handshake, and the server is highly unlikely
to only list the new signature schemes.  (And I think you could decline the
authentication in that case anyway, but didn't double-check.)

The answer could also be "yes" in that if both sides *want* to, it can be done
for client authentication, but in your case you don't want to and are not
obligated to do so.

-Ben

> There can be a performance penalty with RSA-PSS v.s. RSA legacy and more
> issues when private keys are used in client authentication (because e.g.
> they are HSM keys).