On Wed, Jul 30, 2025 at 3:17 AM Martin Thomson <m...@lowentropy.net> wrote:
> On Thu, Jul 24, 2025, at 17:00, Sean Turner wrote: > > This is the working group last call for Legacy RSASSA-PKCS1-v1_5 > > codepoints for TLS 1.3. Please review draft-ietf-tls-tls13-pkcs1 [1] > > and reply to this thread indicating if you think it is ready for > > publication or not. If you do not think it is ready please indicate > > why. This call will end on at 2359 UTC on 07 August 2024. > > A few minor things: > > > Clients SHOULD NOT negotiate them with keys that support RSASSA-PSS. > > This is a "SHOULD NOT" without explanation, but I wonder if this could be > a "MUST NOT" instead. Validation of these will be possible because PSS is > mandatory to support. > The reason for a SHOULD NOT is that, at the layer of the TLS stack, detecting whether you have PSS support may not be possible. At the level of APIs exposed by OSes, etc., not everything has a robust way to detect support for an algorithm, and trialing a signature might trigger UI. On the flip side, this situation only matters for you if your client was willing to use that key with PKCS1 at TLS 1.2. If that were vulnerable to forgeries, you could be impersonated at TLS 1.2 anyway. I think a MUST-level requirement is thus inappropriate. It's nice, in theory, to encourage folks to move up to PSS where they can, but I think that points to a SHOULD. I added a brief explanation in https://github.com/tlswg/tls13-pkcs1/commit/b2cafbed01f20d432363838dafc4100e9aeaa560 > > TLS implementations SHOULD disable these code points by default. > > Another "SHOULD"; maybe the context is enough to cover the explanation, > but it might be worth adding some: "These algorithms are not safe to use in > the general case; see {{security}}." > Added a pointer to Security Considerations in https://github.com/tlswg/tls13-pkcs1/commit/cd690cedae1d611c7a344c3eb4bb9ae7feaa846b I did not add the text about "not safe for use in the general case", as that is a bit too hyperbolic. If we really believed that, we would be in a bit more of a hurry to get rid of PKCS1 in the PKI, and TLS 1.2, but we're (correctly) not. We switched TLS 1.3 to PSS because this was believed to be an easy thing we could do "for free" with existing keys. We have since learned this was very much not free. PSS came too late and we should have skipped it IMO. Should PKCS1 actually fall now, PSS is basically strictly worse than ECDSA both in performance and compatibility. On top of that, it was catastrophically mis-standardized with too many parameters at every layer. If we had a time machine and made PSS *the* RSA signature scheme, with *one* set of universally-agreed parameters, it'd be another story. But here we are and TLS 1.3 is what it is. We picked the worst of both worlds, and have to make the best of it. > > external fallbacks break TLS's security analysis and may introduce > vulnerabilities [POODLE]. > > TLS 1.3 -> TLS 1.2 external fallbacks are (doubly) protected. Maybe not > as well as you might like, but I'm not sure that you need to elaborate this > particular point. > This is not true I'm afraid. I assume by double you mean Finished and server random? All downgrade protection mechanisms in TLS happen within the context of the particular client configuration that the TLS protocol sees. If you externally disable TLS 1.3, all those mechanisms will be evaluated against a client that does not support TLS 1.3. The sole[*] existing downgrade protection for an *external* fallback is FALLBACK_SCSV, but that does not apply here. That signal means "dear server, you seem to be TLS N+1 intolerant, fail the connection if you disagree". But the trigger here is not that the server is TLS N+1 intolerant. It's that the particular combination of client configuration and server configuration does not work at TLS 1.3. We would need a *new* SCSV to protect that, because existing servers will (correctly) reject FALLBACK_SCSV if they understand TLS N+1. Now, what *could* protect this is if the trigger for *this* hypothetical fallback were protected. That is, we ensure an attacker could not trigger the fallback where it would not naturally have been triggered. Doing that is very precarious because of particulars of TLS 1.2. If the client did not trigger the fallback on any client certificate negotiation error, but specifically in response to a TLS 1.3 CertificateRequest, it *might* work? But it's very subtle to get it right. For example: - The client MUST have verified the server certificate already, otherwise the CertificateRequest is not authenticated and an attacker could spoof it. - The client MUST NOT trigger this in response to, say, a TLS 1.2 PSS-only CertificateRequest. TLS 1.2 CertificateRequests are never authenticated and an attacker can always[**] spoof it. Given how subtle this all is, I think a reminder in the text that it "break[s] TLS's security analysis and may introduce vulnerabilities" is quite well-founded. :-) David [*] I suppose in theory you could make a TLS API that configures two maximum versions, and then you evaluate the TLS 1.3 server random signal against the hidden one, a la FALLBACK_SCSV. I'm not aware of anyone who did this. Regardless, it would hit the same problems as trying to reuse the existing SCSV. You can't reuse the signaling for one fallback condition to protect a different fallback condition. [**] An aside, this actually has some very subtle consequences, because TLS 1.2 also sends client certificates in the clear. If your server moves to TLS 1.3, the attacker can still forward a TLS 1.2 response and forge a ServerHello..CertificateRequest..ServerHelloDone. It won't be able to complete the handshake and send server Finished, but the client will have sent a cleartext client certificate already. This works as long as the client still supports TLS 1.2. The server random would, in theory, prevent that, but the attacker can then forge RSA key exchange + CertificateRequest and bypass it. This works as long as the client still supports RSA key exchange (even if the server doesn't!). *If* the server doesn't, it in theory can protect that by removing keyEncipherment from its keyUsage extension... as long as the client correctly checks the chosen TLS 1.2 cipher suite against keyUsage, and many don't. I know because we do, and ran into a host of compatibility issues from other clients not checking. :-) It's all a huge mess.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
