Résumé

  • RFC 9761 permet au fabricant de déclarer le profil TLS et DTLS attendu d’un objet connecté ; cette déclaration fournit une référence, pas une attestation de l’intégrité du terminal.
  • Un paramètre connu mais absent du profil peut motiver une action. S’il est inconnu du pare-feu, le blocage fondé sur cette seule ignorance est incorrect ; si le profil le déclare, l’alerte vise d’abord l’analyseur devenu obsolète.
  • TLS 1.3, ECH et le DNS chiffré réduisent l’observation passive. Un proxy récupère de la visibilité au prix d’une nouvelle frontière de confiance et de confidentialité.

La mise à jour du capteur avait été signée, déployée et testée. Au premier redémarrage, pourtant, le pare-feu a classé son ClientHello comme anormal. La nouvelle valeur n’apparaissait pas dans l’ancien profil. Surtout, le pare-feu ne disposait d’aucun nom pour elle.

Cette seconde absence change le diagnostic. RFC 9761 ne demande pas à l’équipement de sécurité de deviner. Si la valeur est connue de lui mais absente du profil MUD, elle devient un écart interprétable. Si elle est inconnue des deux côtés, la session ne doit pas être bloquée pour ce seul motif. Le contrôleur doit conserver le passage, signaler son incertitude et apprendre.

Le profil décrit une attente, non un état intérieur

Le point de départ de RFC 8520 est raisonnable : un objet spécialisé possède généralement un comportement réseau plus étroit qu’un ordinateur polyvalent. Le fabricant peut publier une Manufacturer Usage Description ; le réseau local peut l’utiliser pour construire des règles. Le fabricant expose une intention. L’opérateur garde la décision et la responsabilité de l’appliquer.

RFC 9761 ajoute les caractéristiques TLS et DTLS à cette description. Le modèle prolonge les ACL de RFC 8519. Versions, suites cryptographiques, extensions, groupes, algorithmes de signature, modes PSK, ALPN, ancres de confiance, autorités de certification acceptables et compression de certificat peuvent être déclarés. La comparaison devient donc plus fine qu’un simple couple adresse-port.

Mais le statut probatoire ne change pas. Le fichier dit ce qui est attendu pour un modèle. La capture dit ce qu’un échange a exposé. Le pare-feu dit ce que sa version sait reconnaître. Même réunis, ces éléments ne mesurent pas directement le code exécuté.

La matrice que le voyant vert efface

Quatre états existent. Profil et pare-feu connaissent la valeur : elle est attendue, sans être pour autant bénigne. Le pare-feu connaît une valeur que le profil omet : l’écart peut signaler un logiciel non autorisé, une compromission, une mise à jour légitime ou un mauvais rattachement de modèle. Une alerte, une quarantaine ou un blocage relèvent alors d’une politique locale documentée.

Le profil connaît la valeur mais pas le pare-feu : c’est l’outil de contrôle qui a pris du retard. RFC 9761 prévoit qu’il ignore ce paramètre pour la comparaison, laisse passer selon la politique et alerte son fournisseur ainsi que le propriétaire de l’objet. L’événement ne doit pas être rangé sous « terminal compromis ».

Enfin, ni le profil ni le pare-feu ne connaissent la valeur. Le comportement conforme reprend l’invariant des intermédiaires de TLS 1.3 : ignorer ce que l’on ne comprend pas, au lieu d’en faire une interdiction. La valeur pourra être qualifiée après mise à jour. Entre-temps, l’incertitude appartient au classificateur.

GREASE vérifie que la porte n’est pas soudée

RFC 8701 réserve des valeurs GREASE que les clients annoncent précisément pour exercer le traitement des extensions inconnues. RFC 9761 interdit de les inscrire dans le profil MUD. Les considérer comme des écarts hostiles reviendrait à casser le test qui protège l’évolution de TLS.

Les registres IANA des paramètres TLS, des paramètres YANG et de MUD fixent un vocabulaire partagé. Ils ne chargent pas automatiquement ce vocabulaire dans un équipement. La date du registre, la révision du module et la version de l’analyseur doivent donc rester dans la preuve.

Cette chronologie redistribue le pouvoir. Un pare-feu fermé par défaut sur toute nouveauté peut retarder l’adoption d’une extension jusqu’à ce que son fournisseur décide de la reconnaître. Le mécanisme « laisser passer et alerter » ne retire pas l’autorité de l’opérateur sur les risques connus. Il empêche seulement un fournisseur en retard de transformer son retard en norme mondiale.

TLS 1.3 retire une partie du témoin

Avec TLS ou DTLS 1.2, ClientHello, ServerHello et Certificate circulent en clair. TLS 1.3 chiffre la quasi-totalité de la poignée de main après ClientHello. DTLS 1.3 suit la même évolution. Un observateur passif peut comparer certaines offres, mais il ne voit plus le certificat du serveur et ne peut pas prétendre avoir contrôlé tout le profil.

ECH masque notamment SNI et d’autres champs sensibles. Le DNS chiffré peut masquer la résolution qui donnait son contexte au nom. Un résolveur choisi hors du réseau déplace le point d’application et peut rendre la politique MUD par nom inopérante. DDR et DNR permettent de désigner des résolveurs chiffrés ; encore faut-il prouver que le terminal suit cette désignation.

Pour voir davantage, un intermédiaire peut terminer TLS. RFC 9761 limite cette option aux objets possédés et gérés par l’entreprise, sous ses exigences de sécurité et de confidentialité, et déconseille le proxy chaque fois que possible. Ce n’est pas une note de bas de page. L’intermédiaire accède potentiellement à des données personnelles ou médicales, devient un point de confiance et déplace la validation des certificats.

Les recommandations de RFC 9325 aident à reconnaître des choix cryptographiques faibles. OSCORE illustre une autre répartition : les objets applicatifs peuvent rester protégés de bout en bout même si un intermédiaire agit sur une autre couche. Ces références éclairent les options ; elles n’autorisent aucun proxy à la place du propriétaire du risque.

Une imitation reste possible

Un agent malveillant peut reprendre les paramètres d’un client légitime. Les différences entre modèles, les autorités de certification, la destination et le rythme des mises à jour rendent la copie coûteuse. RFC 9761 précise néanmoins qu’elle n’est pas impossible. Un profil conforme réduit un soupçon ; il ne ferme pas l’enquête.

Il faut conserver le lien avec l’objet et le modèle, le hachage et la signature du fichier MUD, sa révision, le logiciel effectivement observé, le code du paramètre, la génération du pare-feu, le contexte DNS et IP, l’état ECH, la présence d’un proxy, l’action locale et le résultat applicatif. L’attribut is-supported peut indiquer une fin de support ; il ne déclare pas à lui seul un appareil défectueux.

La séparation des couches de réalité empêche ainsi une déclaration signée de prendre la place du terminal réel. La primauté du code en fonctionnement oblige à identifier les versions réellement chargées. Une spécification initiale minimale et une décision future locale donnent un langage commun sans confisquer le choix de bloquer.

Le meilleur résultat de RFC 9761 n’est donc pas une certitude artificielle. C’est une incertitude attribuée au bon propriétaire.