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). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
