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 <andrei.po...@microsoft.com> 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
