Résumé

  • Le 3 septembre 2026, l’IESG a approuvé comme Proposed Standard le profil TLS/DTLS 1.3 destiné à l’Internet des objets. Le texte prévoit le renouvellement des ancres de confiance, mais une norme ne peut pas attester que chaque appareil a réellement changé d’autorité.
  • Une migration défendable exige un registre par appareil : distribution autorisée, écriture durable, génération active, chaîne présentée et acceptée, possibilité de retour, extinction de l’ancienne autorité et reçu applicatif.

L’annonce de l’IESG porte sur draft-ietf-uta-tls13-iot-profile-25. Le Datatracker indique que l’annonce d’approbation a été envoyée, sans numéro RFC définitif dans le dossier consulté. Le texte approuvé complète le profil TLS/DTLS 1.2 de la RFC 7925 et actualise notamment les exigences relatives aux certificats X.509 et aux suites cryptographiques.

Le point opérationnel décisif n’est pas la version du protocole. Des équipements peu accessibles peuvent rester en service pendant des années, alors que l’algorithme, la CA, le fabricant ou l’exploitant changent. Le document reconnaît qu’une ancre figée pour toute la durée de vie rend ces transitions et la réaction à un incident beaucoup plus difficiles.

Une ancre n’est pas un certificat que le serveur peut simplement envoyer pour se faire croire. Le certificat racine reçu dans le message Certificate ne devient pas digne de confiance par sa seule présence. Le profil privilégie un approvisionnement hors de la poignée de main et l’omission de la racine dans la chaîne transmise. La possession de l’autorité d’installation devient donc une composante du contrôle de l’appareil.

Trois modes, trois chaînes de garde

Le profil couvre les certificats X.509, les clés publiques brutes et les PSK externes. Cette pluralité est utile, mais elle interdit de réduire le tableau de bord à « TLS activé ».

Avec X.509, il faut distinguer l’ancre, les CA subordonnées et le certificat d’entité finale. Une clé publique brute au sens de la RFC 7250 évite la structure du certificat dans l’échange, mais ne prouve pas à elle seule l’identité attendue : l’association entre clé et pair doit être protégée ailleurs. Un certificat auto-signé reste, quant à lui, un objet X.509.

Les PSK externes déplacent encore la garde. La RFC 9257 décrit les risques d’entropie, d’identité et de déploiement; la RFC 9258 définit l’importation liée au contexte TLS 1.3. Il faut toujours savoir qui a créé le secret, quels appareils le partagent, quand il change et à quels services il donne accès.

Le pont entre deux CA ne constitue pas une arrivée

Lors d’une cession de fabricant, les appareils ne migrent pas tous ensemble. L’extension certificate_authorities peut aider le serveur à choisir une chaîne compatible avec les CA annoncées par un pair. Les certificats transitoires newWithOld et oldWithNew décrits par la RFC 9810 peuvent relier deux générations. Ils ne remplacent pas l’installation hors bande de la nouvelle ancre.

Le danger tient à la réussite apparente. Tant que le serveur présente un chemin compatible avec l’ancienne CA, les appareils dormants se reconnectent et les indicateurs restent verts. Mais l’ancienne organisation conserve un pouvoir d’authentification. Sans date de sortie assortie de preuves, le pont devient une architecture permanente.

Couper trop tôt produit le risque inverse. Un équipement isolé qui n’a pas enregistré la nouvelle ancre peut perdre le seul canal authentifié capable de le réparer. Le registre doit donc montrer, pour chaque unité, la dernière génération installée, le chemin réellement validé et le dernier usage observé de l’ancienne autorité.

Recevoir une mise à jour n’est pas l’installer

Le profil cite la mise à jour sécurisée du micrologiciel comme moyen de distribuer de nouvelles ancres. L’architecture SUIT de la RFC 9019 sépare auteur, distributeur, appareil et relations de confiance. Toutefois, une livraison réussie précède encore la vérification du paquet, l’écriture persistante, l’activation, le redémarrage, la relecture du magasin et une connexion utilisant effectivement la nouvelle ancre.

Le périmètre a aussi une limite : cette distribution ne règle pas automatiquement le renouvellement des certificats d’entité finale ou de CA subordonnée. L’EST de la RFC 7030 offre des mécanismes d’enrôlement et d’obtention de certificats de CA; leur présence et leur réussite doivent être attestées dans le déploiement concerné.

Un taux global de 98 % mélange des conséquences différentes. Les 2 % restants peuvent être des capteurs remplaçables ou les actionneurs uniques d’un site distant. Le dénominateur doit conserver l’identité de l’appareil, sa génération matérielle, son micrologiciel, ses empreintes d’ancres, le résultat de mise à jour, la dernière présence et le propriétaire de l’exception.

Réduire les octets peut déplacer la dépendance

Les limites de mémoire sont réelles. Lorsque le tampon par défaut d’environ 18 Ko est inacceptable, Record Size Limit, défini par la RFC 8449, permet d’annoncer une taille de record recevable. Ce nombre ne mesure ni la RAM totale, ni l’énergie, ni le temps de vérification des certificats.

La reprise de session selon la RFC 9846 évite de répéter certaines authentifications, mais le nombre, la durée et la réutilisation des tickets touchent l’état serveur, la vie privée et le rejeu. Le profil IoT n’autorise pas à lui seul le 0-RTT pour CoAP ou MQTT sans règles applicatives adaptées.

La compression des certificats, les certificats mis en cache ou les URL de certificats réduisent le trafic direct. Ils introduisent parfois un cache, un service de récupération ou un identifiant stable. L’économie de bande passante peut donc agrandir la surface d’autorité et de disponibilité.

Le registre de génération de confiance

Pour chaque appareil, inscrire la génération matérielle, le micrologiciel, le démarrage sécurisé, la racine de mise à jour, le mode d’identification, les empreintes d’ancres acceptées et leur rôle. Pour chaque transition, conserver l’autorisation, la livraison, la vérification, l’écriture durable, l’activation, le redémarrage et la relecture.

Ajouter ensuite le chemin présenté par le service et celui qu’a effectivement accepté l’appareil : certificat final, CA subordonnée, génération d’ancre, protocole négocié et heure d’observation. Le reçu de l’application reste séparé. Une poignée de main authentifie un pair suivant un chemin; elle ne prouve pas qu’une commande a été autorisée, enregistrée ou exécutée physiquement.

La discipline des couches de réalité de Lu Heng évite ces substitutions : le statut de norme est symbolique, le magasin est un état configuré, la validation est un événement exécuté et la continuité est un résultat. Running-Code Primacy place l’état observé avant la fiche produit. Le principe de spécification initiale minimale et décision future localisée explique pourquoi l’interopérabilité commune n’impose pas une topologie unique de CA.

Sources