Résumé

  • Martine Sophie Lenders et ses coauteurs ont testé si un classifieur pouvait reconnaître des trames DNS chiffrées parmi des trames de données applicatives dans des scénarios IoT contraints.
  • Avec le transfert par blocs de CoAP et la compression d’en-têtes SCHC, la précision de Random Forest tombe à 77 %–86 % selon le format ; la longueur du dernier bloc laisse encore une empreinte.

Une requête DNS peut devenir illisible sans que son paquet cesse d’être reconnaissable. Sur un petit objet connecté, effacer cette silhouette a un coût : quelques octets de remplissage peuvent entraîner fragmentation, énergie dépensée et délais sur un lien déjà étroit.

Martine Sophie Lenders travaille précisément à cette frontière. TU Dresden la présente comme doctorante à Freie Universität Berlin et collaboratrice scientifique de sa chaire Distributed and Networked Systems. Avec Thomas C. Schmidt et Matthias Wählisch, elle a posé une question plus pointue que « le DNS est-il chiffré ? » : un observateur peut-il reconnaître le trafic DNS sans lire la requête ?

Le contexte normatif est déjà là. Le RFC 9953, dont Lenders est la première autrice, définit DNS over CoAP pour les appareils contraints. Les messages CoAP peuvent être protégés par TLS, DTLS ou OSCORE. Le chiffrement protège le contenu ; il ne transforme pas automatiquement la taille et les champs visibles du paquet en trafic indifférencié.

Pour mesurer cette différence, l’équipe a construit un corpus à partir de 58 768 objets de données et modélisé 296 scénarios de résolution selon plusieurs réglages réseau et protocolaires. Elle a comparé six classifieurs, retenu Random Forest pour l’analyse détaillée des en-têtes et utilisé une validation croisée en cinq blocs. La cible était une classe de trafic — trame DNS ou trame de données — pas le texte de la requête, le nom demandé ni l’identité d’un appareil.

Le résultat utile est aussi celui qui dérange : associer le transfert par blocs de CoAP à des règles SCHC par pair ramène la précision de classification entre 77 % et 86 %, selon le format DNS et le format des données. Le dernier bloc reste souvent révélateur parce que sa longueur n’est pas égalisée.

Lenders et ses coauteurs font d’une contrainte des appareils une commande de confidentialité. CoAP peut transporter les données par blocs de taille fixe ; SCHC peut supprimer ou compresser des champs qui renseignent sur la destination ou le type d’un paquet. Le dernier bloc réclame encore un traitement. L’article étudie son remplissage jusqu’à la taille complète, tout en rappelant qu’un remplissage aveugle grossit les paquets et peut provoquer de la fragmentation sur les liaisons à faible consommation.

Voilà pourquoi « chiffré » ne clôt pas le dossier. Quelqu’un choisit les en-têtes conservés, la forme des blocs et l’endroit où résident les règles de compression. Lenders remet ce choix au centre du travail des concepteurs de protocoles et des opérateurs d’objets connectés.

Pour passer d’un résultat de conception à un constat opérationnel, il manque des traces de paquets issus de déploiements réels de DNS over CoAP ; les auteurs en font une piste de recherche. Sources : la publication de TU Dresden, l’article original, le RFC 9953 et le profil de Lenders à TU Dresden.