Résumé

  • En TLS 1.2 et DTLS 1.2, le RFC 10015 interdit aux clients de proposer et aux serveurs de choisir plusieurs échanges Diffie–Hellman sur corps fini ainsi que l’échange RSA statique. L’ECDH statique et certains types de certificat client DH restent au niveau « SHOULD NOT ».
  • Le D du registre IANA atteste une décision normative, pas son exécution. Une preuve crédible de désactivation doit relier la règle, la configuration effective, son chargement, chaque terminaison, les tests de négociation, la télémétrie et la fin des exceptions.

La politique centrale était correcte. Le dépôt de configuration l’était aussi. Pourtant, un ancien terminateur DTLS, administré séparément, continuait d’exécuter l’image précédente. Dans le tableau de conformité, la suite était « abandonnée » ; sur le réseau, elle restait sélectionnable.

Ce décalage n’est pas un défaut du RFC 10015. Ce texte de la filière normative IETF précise ce que les pairs TLS 1.2 et DTLS 1.2 ne doivent plus faire. Il ne prétend ni recenser les produits, ni mesurer Internet, ni pousser une configuration dans les équipements. Le problème naît lorsque l’organisation transforme une décision de normalisation en constat d’exploitation.

La tentation est forte parce que le registre est structuré. Un robot lit une nouvelle valeur, déclenche un contrôle et produit un voyant vert. Il a pourtant observé la couche la plus éloignée du trafic : le statut public de la recommandation. Entre ce statut et une négociation se trouvent le code disponible, les valeurs par défaut, les politiques locales, leur rendu, le rechargement des processus, l’inventaire des points de terminaison et les offres des clients.

Les verbes normatifs ne se valent pas

Le RFC 10015 ne traite pas tous les mécanismes comme une seule famille indistincte. Pour TLS 1.2 et DTLS 1.2, un client MUST NOT proposer et un serveur MUST NOT choisir les suites Diffie–Hellman non éphémères sur corps fini. La même interdiction vise les suites DHE éphémères dans ces versions. L’échange de clés RSA statique entre lui aussi dans cette catégorie.

Le statut de l’ECDH statique est SHOULD NOT. Celui des types de certificat client à DH fixe est également SHOULD NOT. Une dérogation exige donc une justification sérieuse, mais elle n’a pas la même signification qu’un écart à MUST NOT. Si l’outil ne conserve que le mot « déprécié », il efface précisément la nuance qui permet de gouverner l’exception.

La version du protocole fait partie du fait. Le RFC 8996 avait déjà déprécié TLS 1.0 et 1.1. Le RFC 5246 spécifie TLS 1.2, tandis que le RFC 8446 remanie l’accord de clés en TLS 1.3. Le RFC 10015 autorise explicitement FFDHE en TLS 1.3 : les problèmes visés en TLS 1.2 ne condamnent pas tout Diffie–Hellman éphémère dans toute version. Le RFC 7919 reste pertinent pour comprendre la négociation des groupes sur corps fini.

Il faut aussi lire « RSA statique » jusqu’au bout. Il s’agit d’un échange de clés, pas d’une interdiction générale des certificats RSA ou des signatures RSA. Un inventaire de certificats qui repère la chaîne « RSA » ne répond donc pas à la question posée par la norme : quel chemin d’échange de clés le pair peut-il proposer ou sélectionner ?

Les motifs cryptographiques donnent leur poids à ces distinctions. L’absence de confidentialité persistante peut exposer des sessions passées après la compromission d’une clé durable. La réutilisation des clés DH sur corps fini alimente des risques de temporisation et de mauvais groupes ; la réutilisation ECDH ouvre des surfaces liées aux courbes invalides, aux canaux auxiliaires et aux fautes. L’échange RSA statique porte l’héritage des attaques de type Bleichenbacher et des réutilisations de clés entre protocoles. Le RFC 9325 et le RFC 9847 replacent ces choix dans une discipline plus large : les conseils de déploiement doivent suivre les preuves accumulées, non la simple persistance d’un ancien code.

Ce que signifie réellement le D

Le registre IANA des paramètres TLS marque désormais les suites concernées et quatre valeurs ClientCertificateType d’un D, avec renvoi au RFC 10015. D signifie « discouraged ». La force exacte — SHOULD NOT ou MUST NOT — demeure dans le texte cité.

Ce marquage prouve l’état du registre. Il peut alimenter une règle d’achat, une analyse de source ou une file de migration. Il ne prouve pas que la bibliothèque a retiré la capacité, que le fournisseur a changé son défaut, que la configuration locale a été modifiée, que le processus l’a chargée, ni que chaque SNI, écouteur, mandataire ou site régional a reçu la mise à jour.

Il ne prouve pas davantage que les clients ont cessé de proposer la suite, que les serveurs ne la sélectionnent plus, ou qu’une exception et une image de retour arrière ne peuvent pas la réactiver. Chacune de ces affirmations a un propriétaire, une horloge et une méthode de preuve différents.

Quatre colonnes au lieu d’un voyant

Une vérification sérieuse sépare capacité, proposition, sélection et observation. Une bibliothèque peut conserver du code tandis qu’une politique empêche toute proposition. Une suite peut rester écrite dans un fichier mais perdre face à une règle supérieure. Un scanner peut ne jamais l’observer parce qu’il ne connaît pas le bon SNI, n’atteint pas l’UDP, ignore un frontal interne ou présente toujours un meilleur choix.

Un test négatif contrôlé, qui ne propose que la famille interdite et attend le refus, apporte une preuve plus précise qu’une connexion ordinaire d’un navigateur récent. Même alors, son résultat ne vaut que pour l’adresse, le port, le transport, le nom SNI et la version de politique effectivement atteints.

Le DTLS 1.3 défini par le RFC 9147 rappelle que l’inventaire doit inclure protocole et transport. Une campagne TCP ne ferme pas une exposition DTLS sur UDP. Un même service peut terminer TLS au CDN, au répartiteur régional, au mandataire d’origine et dans un maillage interne ; la conformité globale n’existe pas sans dénominateur.

Le reçu de clôture de dépréciation

Pour chaque exposition, il faut établir un reçu de clôture de dépréciation. La première partie nomme l’élément IANA, le RFC, la version du protocole, la famille d’échange et la force normative. Elle évite de supprimer à tort FFDHE en TLS 1.3 ou de traiter un SHOULD NOT comme un MUST NOT.

La deuxième partie localise le contrôle effectif : source de configuration faisant autorité, version validée, politique rendue, version du logiciel ou de l’équipement, adresse, port, transport, écouteur, SNI et mandataires en amont. Une politique de parc ne vaut pas preuve de terminaison quand plusieurs équipes et produits terminent le même service.

La troisième partie atteste l’activation : redémarrage, rechargement à chaud ou déploiement géré ; heure ; identifiant du changement ; population cible ; instances réussies, échouées ou absentes ; version de retour arrière. Le diff exprime une intention. L’identité du processus et sa politique chargée rapprochent la preuve du comportement.

La quatrième partie contient les tests et la télémétrie. Elle conserve les offres reçues, les sélections réalisées, la fenêtre d’observation et les trous de couverture. « Non vu » ne devient jamais « impossible » par un simple changement de libellé.

Enfin, le reçu nomme chaque dépendance ancienne et chaque exception : usage, périmètre, mesure compensatoire, responsable, approbation, échéance et critère de sortie. La migration du client et le retrait du chemin de compatibilité doivent tous deux être constatés. Sans date d’expiration, une exception devient une politique parallèle.

Ce reçu est une proposition de gouvernance de Daniel Kade, pas une exigence ajoutée au RFC. Il sert à empêcher qu’une donnée normative, parce qu’elle est facile à lire par une machine, ne fabrique une certitude sur un système que la machine n’a pas inspecté.

Dire seulement ce que l’on sait

L’automatisation devrait publier des états précis : « registre déprécié », « retiré de la configuration », « rechargement vérifié », « offre interdite refusée », « aucune sélection observée dans cette couverture », « exception close ». Le mot « désactivé » ne vient qu’après la fermeture de tous les chemins pertinents.

Cette précision rend aussi l’incident réparable. Si une sélection interdite réapparaît, l’équipe peut remonter à la source de politique, au rendu, au déploiement, à l’inventaire, à l’exception ou au client retardataire. Un unique bit de conformité ne conserve aucune de ces causes.

La normalisation a fixé le point de départ. L’exploitation doit encore répondre à la question décisive : quel processus en cours d’exécution peut toujours faire l’ancien choix, et qui possède la preuve que cette possibilité a disparu ?

Sources