Résumé

  • RFC 9851 arrête l’approbation de nouvelles fonctions pour TLS 1.2, sauf correctif de sécurité urgent reconnu par consensus du TLS Working Group et sauf inscriptions ALPN Protocol IDs ou TLS Exporter Labels. Aucun registre TLS n’est fermé.
  • Ce gel ne concerne aucune version de DTLS et ne modifie aucun terminal. Pour parler de retrait, il faut encore identifier les points de terminaison, lire leur configuration, observer les négociations et faire répondre les propriétaires des dépendances.

Le comité d’architecture s’étonna de voir une nouvelle ligne dans le registre IANA après le « gel » de TLS 1.2. Deux conclusions opposées apparurent aussitôt. Pour les uns, le gel n’existait donc pas vraiment. Pour les autres, la nouvelle inscription prouvait que TLS 1.2 venait de recevoir une capacité supplémentaire.

Les deux lectures confondaient un registre demeuré ouvert avec une branche fonctionnelle fermée.

Ce cas est construit ; il ne décrit ni produit ni déploiement réel. RFC 9851, Proposed Standard de l’IETF publié en juillet 2026, porte un titre sans détour : TLS 1.2 is in Feature Freeze. Le texte refuse les changements futurs à TLS 1.2, sauf corrections de sécurité urgentes déterminées par consensus du TLS Working Group et deux exceptions de registre.

La décision organise le travail collectif. Elle dit aux auteurs de spécifications, à l’IANA et aux experts désignés quelles extensions peuvent encore entrer dans le bien commun. Elle ne pousse aucune configuration dans un proxy. Elle ne supprime pas un binaire, ne change pas la version minimale d’un service et ne voit pas la version négociée lors d’une connexion.

RFC 5246 reste l’archive normative de TLS 1.2. Une spécification stabilisée et des milliers d’instances vivantes peuvent coexister. « Plus de fonction nouvelle » répond à une question d’évolution ; « plus de session TLS 1.2 » répond à une question d’exploitation.

Même la notion d’urgence conserve un propriétaire précis. Une équipe locale peut juger une faille urgente, mais cela ne constitue pas le consensus du TLS Working Group demandé par RFC 9851. Si le groupe approuvait demain une correction, cette décision ne démontrerait pas davantage que chaque bibliothèque l’a implémentée, que chaque fournisseur l’a distribuée ou que chaque processus l’a chargée.

La section IANA est souvent la source du malentendu. Le document précise qu’il ne ferme aucun registre TLS. Il modifie plutôt les instructions : la plupart des entrées ajoutées après son approbation sont destinées à TLS 1.3 ou aux versions ultérieures et devraient l’indiquer, par exemple dans la colonne Comment. Le registre IANA des paramètres TLS décrit ainsi une attribution et son cadre, pas l’état d’un parc.

Deux espaces conservent leurs règles antérieures : TLS Application-Layer Protocol Negotiation Protocol IDs et TLS Exporter Labels. Un identifiant ALPN nomme le protocole applicatif que des pairs peuvent négocier. Un Exporter Label sépare les usages de matériau cryptographique exporté. Ces noms peuvent rester utiles entre générations sans ajouter à TLS 1.2 un algorithme ou un échange inédit.

Une inscription ALPN n’est donc pas la preuve qu’un serveur offre ce protocole, qu’un client l’a sélectionné ou que l’application a répondu. Un label Exporter ne prouve ni la dérivation effective, ni le contexte, ni l’autorisation de l’action qui suit. L’exception préserve un espace de coordination ; elle n’élargit pas la portée probatoire de la ligne du registre.

RFC 9847 distingue dans les registres ce que l’IETF recommande, n’a pas évalué ou déconseille. Le marquage D doit être expliqué par une référence ou un commentaire. Cette classification est une décision commune précieuse. Elle ne lit toujours pas le fichier de configuration chargé sur un terminal.

La frontière TLS/DTLS est encore plus nette. RFC 9851 exclut expressément DTLS, quelle qu’en soit la version. Une synthèse qui remplace « TLS 1.2 » par « TLS/DTLS 1.2 » ne simplifie pas la décision : elle ajoute un objet que le texte a délibérément retiré.

RFC 9325 formule des recommandations de déploiement pour TLS et DTLS. RFC 10015 traite séparément de méthodes d’échange de clés obsolètes dans TLS 1.2 et DTLS 1.2. L’article déjà consacré à RFC 10015 possède cette analyse détaillée. Ici, la question est différente : quel fait de gouvernance produit un gel fonctionnel, et quelle preuve manque encore pour décrire l’exécution ?

La cryptographie post-quantique donne au gel son poids stratégique. RFC 9851 indique que les travaux PQC du TLS Working Group se concentrent sur TLS 1.3 ou au-delà et qu’aucune solution PQC pour TLS 1.2 ne sera spécifiée. RFC 9958 expose le contexte d’ingénierie ; RFC 9846 définit TLS 1.3.

Cette orientation ne permet pas d’inscrire « prêt pour le post-quantique » à côté de chaque service TLS 1.3. La prise en charge d’une version, l’implémentation d’un mécanisme hybride, son activation, le groupe réellement choisi, l’authentification du pair et le résultat applicatif sont des preuves différentes. Elle ne permet pas non plus de déclarer compromise une session TLS 1.2 observée.

RFC 9852 ajoute une règle voisine pour les nouveaux protocoles utilisant TLS : TLS 1.3 doit être leur choix par défaut ; TLS 1.2 peut rester une option supplémentaire non par défaut lorsque le déploiement l’exige. « Nouveau protocole » n’est pas une décoration. Cette prescription de conception n’exécute pas rétroactivement la migration des services existants.

La spécification initiale minimale de Heng Lu suggère de garder la couche commune étroite : destination des nouveaux travaux, exceptions de registre, autorité sur l’urgence. Le calendrier d’un client ancien ou d’un équipement local demeure une décision de son propriétaire. Agrandir la phrase commune jusqu’à couvrir tout le parc efface ce propriétaire.

Les couches de réalité ordonnent ensuite les pièces : publication du RFC, commentaire IANA, capacité compilée, politique chargée, versions offertes, version sélectionnée, acceptation applicative, effet pour l’utilisateur. Une vérité documentaire n’acquiert pas automatiquement la force de la couche suivante.

La primauté du code exécuté répond à la question opérationnelle. Pour savoir si un service négocie encore TLS 1.2, il faut observer le code, la configuration et la connexion. RFC 9851 explique pourquoi attendre une nouvelle fonction TLS 1.2 n’est plus une stratégie ; il n’observe pas le terminal à notre place.

Un inventaire sérieux part des points de terminaison. Un même service peut terminer TLS dans un CDN, un répartiteur, une passerelle API, un relais et un boîtier ancien. Il faut relier chaque écoute à une bibliothèque et sa version, une plage de protocoles, une politique cryptographique, un certificat, un résultat ALPN, des populations clientes, un propriétaire d’exception et une échéance.

Le succès d’un canari TLS 1.3 prouve une connexion. Il n’exclut pas TLS 1.2 sur une adresse IPv6, un hôte de secours ou le trafic mensuel d’un partenaire. Une courbe à zéro ne vaut preuve négative qu’avec un périmètre de collecte, une durée suffisante et une explication des pertes de télémétrie.

La clôture doit combiner la configuration faisant autorité, la réconciliation d’inventaire, l’observation, des sondes représentatives, l’accord des propriétaires, l’échec contrôlé des clients anciens et l’état du retour arrière. Ces reçus ne sont pas redondants : ils répondent à des risques distincts.

La fiche RFC Editor fixe date, statut, auteurs et groupe de travail. La recherche d’errata permet de contrôler les corrections signalées. Aucune ne constitue une mesure d’adoption ou de conformité d’un produit.

Le gel est donc un signal fort, mais pas un bouton. Il ferme l’espoir d’étendre normalement TLS 1.2, oriente le PQC vers l’avant et rend les nouvelles dépendances plus difficiles à justifier. Seule une chaîne de décisions locales et d’observations peut fermer le dernier terminal.

Sources