Résumé

  • Le 3 septembre 2026, l’IESG a approuvé la version 25 de TLS/DTLS 1.3 Profiles for the Internet of Things comme Proposed Standard. L’annonce ne lui attribue pas encore de numéro RFC définitif.
  • Le texte complète la RFC 7925 et ne la met à jour que pour le profil de certificats X.509 et les suites cryptographiques ; les parcs industriels en TLS/DTLS 1.2 ne disparaissent pas du périmètre.
  • Sa limite centrale est écrite noir sur blanc : la compatibilité TLS est nécessaire, mais ne suffit pas à assurer l’interopérabilité de l’authentification et de l’autorisation.
  • Certificat, clé publique brute et secret prépartagé déplacent différemment la charge d’identité et de cycle de vie. Le succès de la négociation ne décide jamais, à lui seul, du droit d’agir.
  • Un reçu de frontière d’autorisation devrait relier la version du profil, l’identifiant attendu, la règle locale, l’état des ancres, l’âge de la session, le réexamen et la réaction sûre, sans publier les secrets.

La norme s’arrête avant la permission

L’approbation de l’IESG n’est pas symbolique. Elle consacre un travail du groupe Using TLS in Applications et place sur la voie des normes un socle commun pour des objets dont la mémoire, l’énergie et la bande passante sont limitées. Le texte ordonne les modes d’identification, les extensions, les alertes, la reprise de session, les temporisateurs, la taille des enregistrements, les certificats et les suites cryptographiques.

Cette discipline évite que deux produits se déclarent compatibles tout en exigeant des extensions ou des champs incompatibles. Mais la version 25 refuse elle-même le raccourci suivant : une implémentation du même protocole ne crée pas automatiquement une compréhension commune de l’identité ni de l’autorisation. Le protocole vérifie une preuve dans un contexte donné ; l’exploitant attribue à cette preuve un appareil, un rôle et une permission.

Le statut doit rester précis. Le document est approuvé comme Proposed Standard. Il peut encore subir le travail éditorial précédant la publication et l’annonce ne donne pas de numéro RFC final. Ce n’est ni une faiblesse ni une licence pour minimiser l’acte ; c’est la différence entre une décision de processus, un texte publié et la preuve qu’un produit le met en œuvre.

La relation avec la RFC 7925 est elle aussi limitée. Le nouveau profil traite TLS/DTLS 1.3 et corrige les parties certificat et suites de l’ancien profil. Il ne remplace pas les règles 1.2 pour les installations anciennes, notamment industrielles, dont les cycles de certification et de maintenance peuvent durer des années. Une flotte peut donc légitimement contenir plusieurs générations ; son registre doit dire laquelle gouverne chaque appareil.

Le même handshake, trois formes de confiance

Le profil décrit trois familles : certificats, clés publiques brutes et PSK externes. Il ne choisit pas un vainqueur universel. Sécurité, exploitation, coût et capacité déterminent la forme adaptée.

Avec X.509, une chaîne certifie qu’une autorité a lié une clé à un identifiant. Le texte distingue l’IDevID, souvent posé en fabrication pour l’amorçage, du LDevID opérationnel attribué dans le domaine de l’exploitant. La première identité peut permettre d’obtenir la seconde ; elle ne devrait pas devenir, par inertie, une permission permanente d’exploiter le service.

La clé publique brute économise le poids de la chaîne, mais elle doit être reliée par le déploiement au pair attendu. Si SNI est absent parce que l’identité repose sur une clé épinglée, une adresse, un certificat propre ou un PSK, il faut une autre liaison. Sinon, la cryptographie peut reconnaître exactement la bonne clé tout en l’associant au mauvais rôle.

Le PSK externe place encore plus de sens dans le provisionnement hors bande : identité du secret, entropie, domaine d’usage et remplacement. L’usage de (EC)DHE est recommandé afin d’obtenir la confidentialité persistante. Un mode PSK seul n’est acceptable que si la perte de cette propriété a été explicitement acceptée pour le déploiement. Il faut donc un responsable, une portée et une date, et non une case technique sans auteur.

SNI et ALPN réduisent certaines ambiguïtés, mais ne distribuent pas des droits. Le texte dit que l’autorisation dépend des justificatifs authentifiés et de la politique locale. Savoir quel service ou protocole le pair demande n’établit pas qu’il peut ouvrir une vanne, modifier une consigne ou lire une mesure.

La révocation ne disparaît pas : elle change de propriétaire

Beaucoup d’objets contraints n’exécutent ni OCSP ni consultation de CRL pendant la négociation. La version 25 propose alors des certificats opérationnels de courte durée, un enrôlement automatisé et une gestion active. Le contrôle est déplacé vers l’opérateur et l’application, pas supprimé.

Ce déplacement rencontre les sessions longues. Remplacer ou laisser expirer un certificat ne ferme pas automatiquement une connexion déjà établie. TLS ne réévalue pas en permanence sa validité. Lorsqu’une validation continue est nécessaire, l’application doit provoquer une nouvelle authentification ou rompre et recréer la session. Une preuve de renouvellement de certificat ne vaut donc pas preuve de fin des anciennes sessions.

Les ancres de confiance posent un problème de durée plus profond. Un appareil installé pour dix ans peut devoir survivre à une rotation de CA, à un changement de fabricant, à une transition algorithmique ou à un incident. Les mises à jour logicielles et les protocoles de gestion peuvent transporter une nouvelle ancre. Il reste à prouver les états : prévue, livrée, installée, sélectionnée, observée, puis ancienne ancre retirée.

Le reçu public n’a pas besoin d’identifier chaque objet. Il peut publier, par cohorte, le canal de mise à jour, la génération attendue, le taux observé, les exceptions, le délai et l’autorité de retour arrière. Les clés privées, noms internes et topologie restent protégés.

L’économie de paquets est un choix de gouvernance

Dans l’exemple minimal de la version 25, deux certificats ECC occupent environ 40 % de la charge utile d’une négociation TLS 1.3 avec authentification mutuelle. Des chaînes courtes, la compression, le cache et la reprise de session réduisent le coût. Ils créent aussi des dépendances.

Le nombre de tickets, leur durée et leur réutilisation arbitrent bande passante, calcul, état serveur, risque de rejeu et confidentialité. Un certificat récupéré ailleurs économise des octets mais ajoute DNS, annuaire, invalidation et exposition possible d’un identifiant stable. Le cache accélère aujourd’hui en échange d’une preuve de fraîcheur demain.

La règle sur le 0-RTT est nette : aucun protocole applicatif ne doit l’utiliser sans profil propre définissant les messages sûrs et le repli. À la date de la version 25, le texte n’en recense aucun pour CoAP ou MQTT et ne les autorise donc pas à utiliser le 0-RTT. Une capacité de transport n’est toujours pas une permission applicative.

Même les erreurs renvoient au contrôle local. Un objet sans écran ne peut demander à l’utilisateur s’il faut réessayer, changer d’identifiant ou s’arrêter. L’application doit associer l’alerte à une reprise, une route alternative, un mode dégradé ou un état sûr. La bibliothèque TLS produit le signal ; elle ne décide pas du dommage acceptable.

Un reçu plus petit qu’un audit, plus fort qu’un badge

Le reçu proposé commence par la version du profil et de l’implémentation. Il indique ensuite le mode d’identification, la référence stable du justificatif, le pair attendu, la méthode de liaison, le protocole applicatif, le rôle, la version de la politique et la classe d’action autorisée ou refusée.

Un bloc de cycle de vie ajoute l’ancre active, la génération du certificat ou du PSK, le canal de provisionnement, l’activation observée, l’expiration et le remplacement. Un bloc de session distingue négociation complète et reprise, conserve l’âge du ticket, la dernière réauthentification et la durée maximale. Toute exception à la confidentialité persistante reçoit un propriétaire et une échéance.

Enfin, un bloc de sûreté relie les erreurs aux décisions. Le 0-RTT est indiqué comme désactivé ou, si un futur profil l’autorise, limité à des messages identifiés et à un dispositif anti-rejeu. Les corrections s’ajoutent au registre : écraser l’ancien état empêcherait d’expliquer une connexion née sous une règle antérieure.

La doctrine minimale de Heng Lu sert ici de limite, non de preuve sur un réseau. Le niveau commun doit rester déterministe et vérifiable localement. Les décisions futures peuvent être locales à condition que leur auteur, leur entrée et leur résultat restent visibles. La variation n’est pas le problème ; l’autorité cachée derrière le nom de la norme l’est.

Ce que l’approbation ne démontre pas

Aucune source examinée ne certifie un produit ni une flotte. Aucun incident, défaut de vendeur ou appareil dangereux n’est allégué. L’IESG n’a choisi ni l’autorité de certification, ni le modèle de PSK, ni la table d’autorisations d’un opérateur.

Le texte n’est pas davantage un profil postquantique. Ses recommandations normatives reposent sur la cryptographie classique ; la section PQC est informative et n’ajoute aucune exigence. Les longues durées de vie rendent la transition importante, pas déjà accomplie.

Enfin, le constat sur OCSP et les CRL décrit des objets contraints et un modèle généralement recommandé. Il n’interdit pas ces contrôles à une plateforme qui en a les ressources. La responsabilité consiste à déclarer le choix et à prouver sa voie de remplacement.

La nouvelle norme proposée atteint ainsi son meilleur effet quand on lui refuse un pouvoir qu’elle ne revendique pas. Elle rend le transport plus compatible. Elle laisse la permission à ceux qui peuvent en assumer les conséquences.

Sources

  1. IESG — approbation du profil TLS/DTLS 1.3 pour l’IoT
  2. IETF — version 25 approuvée
  3. RFC 9846 — TLS 1.3
  4. RFC 9147 — DTLS 1.3
  5. RFC 7925 — profils TLS/DTLS pour l’IoT
  6. RFC 5280 — profil PKI X.509
  7. RFC 9257 — PSK externes
  8. RFC 9258 — import des PSK
  9. RFC 9019 — mise à jour des micrologiciels IoT
  10. RFC 8995 — BRSKI
  11. RFC 9525 — identité de service TLS
  12. RFC 9325 — usage sûr de TLS et DTLS
  13. Heng Lu — Minimum Initial Specification