Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
I support moving forward with this document. On Wed, 25 Oct 2023 at 04:49, Andrei Popov wrote: > > Hi TLS, > > > > We would like to re-introduce > https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/ > > (it’s intended for the TLS WG and the Standards track, despite what the > document says at the top; we’ll fix it as soon as the submission tool > reopens). > > > > In the course of TLS 1.3 deployment, it became apparent that a lot of > hardware cryptographic devices used to protect TLS client certificate private > keys cannot produce RSA-PSS signatures compatible with TLS. > > This draft would allow RSA-PKCS signatures in the client CertificateVerify > messages (and not in any other contexts), as a way to unblock TLS 1.3 > deployments. > > This is an unfortunate situation, and work is being done with hardware > vendors to reduce the likelihood of similar issues in the future, but > existing devices tend to stay around for years. > > > > Comments/suggestions are welcome, > > > > Cheers, > > > > Andrei > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk 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
Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
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? -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
Some changes from the last time this was posted: - Apparently we got early codepoint allocation for this and I forgot about it? Anyway the allocated codepoints are now in the draft. - We've crisped up the motivation a bit. One thing I'll call out is that the previous discussion mentioned one could stick with TLS 1.2. I think this was already not reasonable back then, because TLS 1.3 fixes a serious privacy and integrity issue with client certificates. (Renegotiation is not a good mitigation. There are loads of problems with renegotiation, which I think this WG is very familiar with, including incompatibility with modern multiplexed protocols.) But, more importantly, new security improvements like post-quantum KEMs to protect against store-and-decrypt-later attacks (rightfully) require TLS 1.3. 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. It saddens me to have to allow RSASSA-PKCS1-v1_5 here, but I think, in the limited scope that this draft covers (client certs only), this is clearly the right move. David On Tue, Oct 24, 2023, 20:48 Andrei Popov wrote: > Hi TLS, > > > > We would like to re-introduce > https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/ > > (it’s intended for the TLS WG and the Standards track, despite what the > document says at the top; we’ll fix it as soon as the submission tool > reopens). > > > > In the course of TLS 1.3 deployment, it became apparent that a lot of > hardware cryptographic devices used to protect TLS client certificate > private keys cannot produce RSA-PSS signatures compatible with TLS. > > This draft would allow RSA-PKCS signatures in the client CertificateVerify > messages (and not in any other contexts), as a way to unblock TLS 1.3 > deployments. > > This is an unfortunate situation, and work is being done with hardware > vendors to reduce the likelihood of similar issues in the future, but > existing devices tend to stay around for years. > > > > Comments/suggestions are welcome, > > > > Cheers, > > > > Andrei > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
This is similar to the case when a server is unable to use its RSA key to sign with PSS passing (my slides for TLS WG in 2015 https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf , presented by Eric), but instead this is about client keys/signatures. I don't have a stake in this currently, but I understand the problem. In both cases the only current solution is to not negotiate TLS 1.3. On Tue, Oct 24, 2023 at 5:48 PM Andrei Popov wrote: > Hi TLS, > > > > We would like to re-introduce > https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/ > > (it’s intended for the TLS WG and the Standards track, despite what the > document says at the top; we’ll fix it as soon as the submission tool > reopens). > > > > In the course of TLS 1.3 deployment, it became apparent that a lot of > hardware cryptographic devices used to protect TLS client certificate > private keys cannot produce RSA-PSS signatures compatible with TLS. > > This draft would allow RSA-PKCS signatures in the client CertificateVerify > messages (and not in any other contexts), as a way to unblock TLS 1.3 > deployments. > > This is an unfortunate situation, and work is being done with hardware > vendors to reduce the likelihood of similar issues in the future, but > existing devices tend to stay around for years. > > > > Comments/suggestions are welcome, > > > > Cheers, > > > > Andrei > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
Hi TLS, We would like to re-introduce https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/ (it's intended for the TLS WG and the Standards track, despite what the document says at the top; we'll fix it as soon as the submission tool reopens). In the course of TLS 1.3 deployment, it became apparent that a lot of hardware cryptographic devices used to protect TLS client certificate private keys cannot produce RSA-PSS signatures compatible with TLS. This draft would allow RSA-PKCS signatures in the client CertificateVerify messages (and not in any other contexts), as a way to unblock TLS 1.3 deployments. This is an unfortunate situation, and work is being done with hardware vendors to reduce the likelihood of similar issues in the future, but existing devices tend to stay around for years. Comments/suggestions are welcome, Cheers, Andrei ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
