Correct, hardware update takes years. Deployments that use client crypto devices without RSA-PSS support (or with an RSA-PSS implementation that produces TLS 1.3-incompatible signatures) have to disable TLS 1.3 on the client and/or server side.
In a lot of these deployments the system admin can detect incompatible client crypto devices and update TLS stacks as needed. Cheers, Andrei From: David Benjamin <david...@chromium.org> Sent: Friday, October 27, 2023 11:34 AM To: Benjamin Kaduk <bka...@akamai.com> Cc: Andrei Popov <andrei.po...@microsoft.com>; TLS@ietf.org Subject: [EXTERNAL] Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk <bka...@akamai.com<mailto:bka...@akamai.com>> wrote: On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote: > Additionally I want to emphasize that, because of the negotiation order > between versions and client certificates, there is no way to do an > incremental transition here. Saying deployments stick with 1.2 not only > impacts the relevant hardware but also *any other connections that the > server makes*. Essentially the server cannot enable TLS 1.3 until *every* > client has stopped using one of these PSS-incapable signers. This is not a > good transition plan. I think we should probably think out the transition plan here a bit more. Sure, if we can have updated clients offer new SignatureSchemes and the server notice that to let them use TLS 1.3. But how does the server get to a place where it can use TLS 1.3 with every client that offers it? It seems like it has to know that all clients with old hardware tokens have updated, which would require knowing about and tracking exactly which clients those are, since other clients would not be sending the new SignatureSchemes in the first place. I see this getting a small win for the legacy clients but no improvement for other clients or the server's default behavior. Am I missing something? Good question. You're right that, because we didn't do this from day one[*], the transition plan is not ideal. Updating software is a lot easier than replacing hardware, so I think waiting for clients with old hardware tokens to update (at least those that have enabled TLS 1.3) can be viable. Most client certificate deployments that stick keys in interesting hardware tokens are relatively closed ecosystems on the client half, such as a managed enterprise deployment. You need to have a provisioning process that knows to use the TPMs. In those cases, it is viable for the enterprise to rollout client support for these legacy codepoints, wait a bit, and then start enabling TLS 1.3 on the servers. Andrei is probably better to speak to how commonly that plan would and wouldn't be viable. If there are enough deployments where this doesn't work, I suppose we could define a ClientHello extension that means "I will either speak the legacy RSASSA-PKCS1-v1_5 codepoints, or it is not relevant to me". Those semantics are pretty messy though, and it makes the server-random downgrade hack much more complex. We can always do it later if enough folks need it, so I'm inclined to defer it for now. David [*] As I recall, TLS 1.3 was broadly intended to be deployable with the same keys as TLS 1.2, otherwise we probably needn't have bothered with RSA at all. We switched from PKCS#1 v1.5 to PSS mostly because it was perceived to cost us nothing. This was broadly true for server certificates. Client certificates not so much. In hindsight, I think banning PKCS#1 v1.5 for client signatures was a tad too ambitious for TLS 1.3.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
