Résumé

  • La version 01 de DNS and mDNS Discovery for MOQT, datée du 5 septembre, a ajouté la normalisation des URI et des règles détaillées de correspondance X.509. La version 02 n’a ensuite corrigé que le lien vers le dépôt source.
  • Pour SVCB et SRV, le texte conserve avec raison l’hôte de l’URI moqt comme identité TLS. Pour la découverte mDNS, il n’explique pas encore comment une annonce locale obtient cette identité de référence ni le droit de parler au nom du service ; sa section de sécurité se réduit toujours à TODO.

Sur l’écran d’un technicien, le résultat paraît simple : « relais trouvé ». En réalité, cette phrase compacte plusieurs autorités. Le paquet est arrivé par une interface locale. Un ensemble PTR/SRV/TXT annonce _moqt._udp. Le TXT contient un ALPN reconnu. Une adresse et un port deviennent joignables. Aucun de ces faits ne démontre que l’équipement appartient à l’organisateur, qu’il représente la bonne production vidéo ou qu’il peut publier dans l’espace de noms attendu.

Le dossier Datatracker situe la version courante au 5 septembre 2026. Le nom du document reste individuel et aucun stream IETF ni niveau de norme n’y est renseigné. L’en-tête vise le Standards Track et renvoie les échanges à la liste Media over QUIC ; cela ne vaut ni adoption par le groupe de travail, ni consensus, ni approbation.

La vraie nouveauté ne vient pas du passage de la version 01 à la version 02. Ce dernier passage remplace seulement l’adresse du dépôt. Elle vient de la comparaison avec la version 00 du 14 août : la version 01 insère un contrat d’identité complet. L’annonce de la version 02 signale donc un projet mieux défini, mais toujours provisoire.

Le serveur de connexion n’hérite pas du nom du service

Le projet prévoit SVCB pour MOQT sur QUIC natif, HTTPS pour le mode WebTransport, SRV comme mécanisme de repli et DNS-SD sur mDNS pour le voisinage local. SVCB et HTTPS transportent notamment l’ALPN ; SRV ne fournit qu’une cible et un port. Le client doit préférer un enregistrement SVCB/HTTPS utilisable.

La version 01 empêche une confusion décisive. Quand SRV ou SVCB renvoie vers une autre machine, cette cible sert à ouvrir la connexion. Le SNI et le certificat restent, eux, contrôlés contre l’autorité de l’URI moqt d’origine. La réponse du DNS choisit un lieu d’exécution ; elle ne réécrit pas le principal auquel le client voulait parler.

C’est l’architecture déjà posée par le RFC 9460 : l’indirection SVCB/HTTPS ne change pas l’origine. Le RFC 9525 ajoute une discipline utile : un nom intermédiaire produit par la résolution n’est pas automatiquement un identifiant de référence. Celui-ci doit provenir d’une entrée configurée ou d’un contexte que l’application sait authentifier.

Le projet rend la comparaison reproductible. Il normalise la casse et certains encodages, ajoute le port 443 absent, retire le point final et convertit les noms internationalisés selon le RFC 5890. Il exclut CN-ID et les jokers. Il admet plusieurs formes de subjectAltName, dont SRVName selon le RFC 4985, sur la syntaxe du RFC 3986.

Cette précision protège une URI déjà connue. Elle ne dit pas encore d’où vient l’URI quand l’expérience commence par une liste de services locaux.

La proximité réseau ne constitue pas un mandat

Dans le parcours mDNS, un relais publie PTR, SRV et TXT sous .local. Le contrôle du TTL IP et de l’adresse source décrit dans le RFC 6762 permet d’écarter des réponses qui ne viennent pas du lien. Il ne distingue pas le relais du lieu d’un appareil hostile déjà présent sur ce lien.

Le même RFC rappelle que la résolution des conflits mDNS suppose des participants coopératifs sans autorité centrale. Dans un environnement antagoniste, il faut d’autres mécanismes. Les noms .local n’emportent aucune autorité globale et la protection cryptographique de bout en bout reste nécessaire. Le RFC 6763 décrit comment construire la découverte de services et recommande DNSSEC lorsque l’authenticité importe ; il ne transforme pas la présence d’un enregistrement en permission.

Or le projet MOQT ne fournit encore qu’un TODO dans ses considérations de sécurité. Il ne définit pas le passage entre l’instance trouvée, l’URI moqt originale qui doit devenir l’identité de référence, et la politique locale qui autorise l’annonceur. Un produit peut combler ce vide par configuration, identité épinglée, domaine signé ou confirmation explicite. Il ne faut simplement pas attribuer ce choix au texte actuel.

Le certificat et l’autorisation ne se remplacent pas

Le projet MOQT Transport 20 compte sur QUIC ou WebTransport pour sécuriser le transport. Il réserve néanmoins à l’application la décision d’autoriser un abonnement, une publication et un espace de noms. Un certificat valide pour le nom de référence répond à une question d’identité. Il ne prouve ni le mandat du lieu, ni les droits sur le contenu, ni la réussite de la session.

Le journal utile doit donc conserver séparément : annonce observée, provenance sur le lien, candidat choisi, URI de référence, résultat X.509, autorisation de l’espace de noms, session et média reçu. Dire seulement « découvert » permet à la première étape d’emprunter la crédibilité de toutes les suivantes.

La spécification initiale minimale de Heng Lu invite à standardiser l’invariant commun sans absorber toutes les politiques locales. Ici, l’invariant juste est que l’indirection ne change pas l’autorité. Les couches de réalité interdisent de confondre annonce, identité et résultat. La primauté du code en fonctionnement exige enfin d’observer ce que le client a réellement vérifié.

Sources

  1. Dossier Datatracker
  2. Projet de découverte MOQT, version 02
  3. Version 01
  4. Version 00
  5. Annonce I-D de la version 02
  6. MOQT Transport, version 20
  7. RFC 9460 : SVCB et HTTPS
  8. RFC 6762 : Multicast DNS
  9. RFC 6763 : découverte de services DNS
  10. RFC 9525 : identité de service dans TLS
  11. RFC 4985 : SRVName
  12. RFC 3986 : syntaxe des URI
  13. RFC 5890 : IDNA
  14. Heng Lu : spécification initiale minimale
  15. Heng Lu : couches de réalité
  16. Heng Lu : primauté du code en fonctionnement