Résumé

  • Pour TLS et DTLS 1.2, RFC 10015 interdit à un client de proposer et à un serveur de sélectionner les suites FFDH/FFDHE et celles dont l’échange de clés est RSA ; l’ECDH statique relève d’un SHOULD NOT.
  • La frontière porte sur la version et sur l’échange négocié : FFDHE reste permis en (D)TLS 1.3 et un certificat RSA peut authentifier un échange éphémère autorisé.
  • La mention D d’IANA décrit une décision commune, pas l’état d’un processus. Inventaire des terminaisons, canaris positifs et négatifs, analyse des échecs, exceptions expirables et contrôle de dérive restent des responsabilités locales.

L’échec qui n’est pas forcément une panne

À 02 h 17, un ancien automate cesse de joindre une API. Le serveur accepte toujours TLS 1.2. Son certificat n’a pas changé. Les clients récents passent. Pour l’équipe d’exploitation, le réflexe est évident : revenir à la chaîne de chiffrement précédente et restaurer le voyant vert.

Cette chaîne réalisait un échange de clés RSA.

Le RFC 10015, publié en juillet 2026 sur la voie des normes, donne à cet échec une autre signification. En TLS ou DTLS 1.2, le client ne doit plus proposer et le serveur ne doit plus sélectionner de suite à échange RSA. Si l’ancien automate ne sait rien négocier d’autre, son refus est peut-être exactement l’effet recherché. Il reste néanmoins un incident de continuité tant que personne n’avait inventorié sa dépendance, nommé son propriétaire et préparé son remplacement.

Ce cas expose la limite d’un indicateur « TLS 1.2 fonctionne ». Une version n’est pas une poignée de main complète. Elle ne dit ni comment le secret a été établi, ni si la clé était éphémère, ni quel groupe a servi, ni quelle couche — application, proxy ou répartiteur — a choisi la suite.

Le texte ne retire pas la version, il trie ses chemins

TLS 1.2 a agrégé des mécanismes très différents sous une même enveloppe. RFC 10015 les sépare avec une précision que la mise en œuvre doit conserver.

FFDH désigne le Diffie-Hellman sur corps fini non éphémère : la clé publique DH statique est contenue dans le certificat. FFDHE place une valeur temporaire dans la poignée de main et l’authentifie au moyen du certificat. ECDH et ECDHE portent la même différence sur les courbes elliptiques.

Pour (D)TLS 1.2, quatre prescriptions gouvernent l’offre du client et la sélection du serveur :

  • FFDH non éphémère : MUST NOT ;
  • FFDHE : MUST NOT ;
  • échange de clés RSA : MUST NOT ;
  • ECDH non éphémère : SHOULD NOT.

Le RFC déconseille aussi les certificats de type rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh et ecdsa_fixed_ecdh. Ces identifiants concernent les versions 1.2 et antérieures.

La différence entre « interdit » et « déconseillé » n’est pas décorative. Une exception ECDH statique doit être rare, argumentée et limitée, mais le texte ne permet pas de la comptabiliser comme la même violation qu’une sélection RSA. À l’inverse, une préférence faible ou une simple baisse dans la liste ne suffit pas pour une suite marquée MUST NOT : le chemin doit devenir impossible à négocier.

Deux faux raccourcis sont particulièrement dangereux. Le premier consiste à bannir tout certificat RSA. Une clé RSA peut signer l’authentification d’un échange ECDHE ; cela n’est pas l’échange de clés RSA visé. Le second consiste à supprimer toute occurrence de DHE. RFC 10015 précise que FFDHE peut encore être proposé en TLS et DTLS 1.3, où la construction ne partage pas les problèmes décrits pour 1.2.

Pourquoi FFDHE 1.2 a perdu son sursis

L’éphémérité est une propriété utile, mais elle ne résout pas toutes les décisions de paramétrage. Dans les déploiements TLS 1.2, le choix du groupe sur corps fini a longtemps été mal négocié. Des serveurs présentent des groupes personnalisés qu’un client ne peut pas raisonnablement vérifier pendant la connexion. S’il refuse le groupe, aucun chemin fiable ne lui permet forcément d’en demander un autre acceptable.

RFC 7919 a introduit des groupes FFDHE nommés et documenté la pression de compatibilité autour de tailles largement prises en charge. RFC 10015 rappelle la persistance de groupes de 1024 bits, la possibilité d’amortir de gros pré-calculs sur des groupes partagés et le risque des petits sous-groupes. L’étiquette « éphémère » ne garantit pas davantage qu’une implémentation renouvelle réellement ses secrets : la réutilisation peut rouvrir des canaux temporels de la famille Raccoon.

Le problème est donc un faisceau : négociation imparfaite, vérification coûteuse, longue traîne des paramètres, compatibilité et discipline de cycle de vie des secrets. Le retirer de TLS 1.2 évite que chaque paire de correspondants doive deviner si cette combinaison est sûre.

L’échange RSA fabrique une dette rétrospective

Avec l’échange RSA de TLS 1.2, le client chiffre le secret initial pour la clé RSA du serveur. La construction n’offre pas de confidentialité persistante. Si un adversaire conserve le trafic puis obtient la clé privée, le passé peut redevenir lisible.

Les oracles de type Bleichenbacher ajoutent une seconde fragilité. Une différence minime dans la manière de traiter un chiffré mal formé peut révéler progressivement le secret. Les variantes ROBOT et DROWN illustrent le retour périodique de cette classe, malgré des années de contre-mesures.

Enfin, la séparation des domaines de clés est peu commode en (D)TLS 1.2. Plusieurs services peuvent partager la même clé RSA. Le point le moins bien protégé devient alors une voie vers un ensemble plus vaste. Une rotation de certificat ne suffit pas si la voie TLS_RSA_* reste sélectionnable ou si la même clé privée demeure exposée ailleurs.

La lettre D n’est pas un démon de configuration

RFC 10015 met à jour dix-sept RFC antérieurs, dont TLS 1.2, DTLS 1.2 et les recommandations BCP 195. Le registre IANA classe les entrées concernées avec D et ajoute le nouveau texte en référence. RFC 9847 définit cette marque comme déconseillée pour les nouvelles implémentations ou les nouveaux déploiements.

Le registre donne un vocabulaire commun. Il ne modifie aucune bibliothèque déjà compilée. Entre sa ligne et la connexion existent le fournisseur cryptographique, les valeurs par défaut du framework, la configuration de l’application, les variables d’environnement, le proxy, le CDN, le répartiteur, le firmware et une éventuelle dérogation régionale.

Une pull request conforme n’est donc qu’une preuve d’intention. L’état effectif se trouve dans la configuration chargée et la suite négociée. Un serveur peut avoir cessé de sélectionner RSA tandis que son client sortant continue de le proposer. Une origine peut être saine derrière une terminaison périphérique qui conserve l’ancien chemin.

Constituer le registre de négociation

Il faut d’abord recenser les lieux de décision : écouteurs publics, API internes, agents sortants, services DTLS, maillages, proxies, équipements et clients embarqués. Pour chacun : propriétaire, bibliothèque, fournisseur crypto, version, suites effectives, règles SNI/ALPN, certificat et usage de la clé, région et population de clients.

L’observation doit ensuite relier le succès à sa voie. Conserver la version négociée, la suite, l’échange de clés et la terminaison qui a décidé. Pour les échecs, enregistrer la première frontière utile : aucune suite commune, groupe refusé, certificat rejeté, désaccord de version ou panne applicative postérieure au transport.

Les canaris rendent la règle déterministe. Un client ne proposant qu’une suite 1.2 interdite doit échouer. Un client 1.2 doté d’un échange éphémère autorisé doit réussir. TLS 1.3 doit rester disponible, y compris son FFDHE lorsque le profil le permet. Une offre mixte doit sélectionner la voie attendue sans repli silencieux.

Le déploiement suit les frontières d’autorité : une classe d’écouteurs, un groupe de clients ou une région à la fois. Chaque étape garde l’empreinte de configuration, les négociations échantillonnées, la distribution des échecs et un paquet de retour arrière. La fin n’est pas le redémarrage du processus, mais l’absence observée du chemin interdit avec continuité des chemins soutenus.

Une norme commune, une preuve locale

La primauté du code en fonctionnement formulée par Heng Lu situe correctement la vérité : ni une approbation, ni une table, ni une intention ne produisent le transcript d’une connexion réelle.

Son principe de spécification initiale minimale et de décision future localisée évite aussi de transformer cette observation en relativisme. Le socle commun peut interdire une combinaison précisément testable. Les participants conservent la décision sur l’inventaire, la séquence, l’isolation d’un client ancien, le remplacement et le retour arrière. Ils ne peuvent pas, pour autant, appeler compatible une voie que leurs pairs ont cessé d’accepter.

RFC 10015 ne pilote pas la flotte à distance. Il rend visible la frontière que chaque propriétaire de terminaison doit désormais appliquer et prouver.