1. Introduction

1. Introduction

TLS 1.3 [RFC8446] a supprimé la prise en charge de RSASSA-PKCS1-v1_5 [RFC8017] dans les messages CertificateVerify au profit de RSASSA-PSS. Bien que RSASSA-PSS soit établi depuis longtemps, certains dispositifs cryptographiques matériels historiques ne le prennent pas en charge. Ces dispositifs sont peu courants dans les serveurs TLS, mais les clients TLS les utilisent parfois pour des certificats clients.

Les Trusted Platform Modules (TPM), par exemple, sont souvent utilisés pour protéger les clés privées de certificats clients TLS. Beaucoup de TPM ne peuvent pas produire de signatures RSASSA-PSS compatibles avec TLS 1.3. Les spécifications TPM antérieures à 2.0 ne définissaient pas la prise en charge de RSASSA-PSS, et les dispositifs TPM 2.0 ne sont fiables pour des longueurs de sel compatibles avec TLS 1.3 que lorsqu'ils sont compatibles avec US FIPS 186-4.

Les déploiements qui restent sur TLS 1.2 exposent les certificats clients aux attaquants réseau [PRIVACY] et ne peuvent pas protéger le trafic contre un déchiffrement rétroactif par un attaquant disposant d'un ordinateur quantique [RFC9954]. TLS négocie également les versions avant les certificats clients; un client et un serveur peuvent donc négocier TLS 1.3 puis échouer ensuite parce que le client possède une clé historique.

Désactiver TLS 1.3 affecte des connexions qui ne seraient autrement pas touchées, tandis que les mécanismes externes de fallback cassent l'analyse de sécurité de TLS et peuvent introduire des vulnérabilités [POODLE]. Ce document alloue des points de code pour utiliser ces clés historiques avec des certificats clients dans TLS 1.3, ce qui réduit la pression en faveur de ces atténuations et débloque le déploiement de TLS 1.3.