Résumé

  • La RFC 9665 utilise SIG(0) pour rattacher un nom au premier détenteur de clé accepté ; cette continuité ne démontre ni l’identité institutionnelle du demandeur ni celle du registraire.
  • NoError, une réplication autoritative, une réponse de résolveur et un service applicatif réussi sont quatre constats différents, à réunir par des reçus séparés.

Un capteur rejoint un réseau et découvre automatiquement un registraire SRP. Il ouvre une connexion DNS sur TLS, envoie une mise à jour signée et reçoit une réponse favorable. Sur le tableau de bord, trois voyants deviennent verts : chiffrement, signature, inscription.

Il manque pourtant une question élémentaire : quelle entité a répondu comme registraire ? La RFC 9665 exige que les registraires proposent TLS et recommande son emploi aux demandeurs capables de l’utiliser. Mais, faute de mécanisme pratique de distribution et de validation des clés du serveur, le texte qualifie ce canal de confidentialité opportuniste. Il réduit l’observation passive ; il ne transforme pas automatiquement le pair en autorité authentifiée.

Cette limite n’annule pas SRP. Elle indique exactement ce que chaque preuve permet d’affirmer.

Une continuité de clé, pas un état civil

SRP adapte DNS Update à l’inscription automatique de services. Plutôt que de provisionner un secret partagé sur chaque appareil, le demandeur crée une paire de clés propre au dispositif. La première mise à jour acceptée contient la clé publique et une signature SIG(0). Tant que le bail de la KEY reste actif, seules les mises à jour signées par la clé correspondante peuvent modifier le nom d’hôte ou d’instance concerné.

Le modèle « premier arrivé, premier servi » établit ainsi une continuité technique : le message actuel vient du même détenteur cryptographique que la revendication initiale. Il n’établit pas le nom légal de l’opérateur, la propriété du matériel, la conformité du logiciel, l’autorisation d’un employé ou l’innocuité du service.

Le demandeur doit conserver sa clé en stockage stable. Un transfert de propriété ou une remise à zéro peut justifier son effacement et la création d’une nouvelle paire. La conséquence est opérationnelle : l’ancien nom reste lié à l’ancienne clé jusqu’à expiration de son bail. Le nouvel appareil doit attendre, choisir un autre nom ou signaler un conflit. La gestion des clés et celle des noms forment donc un seul processus de cycle de vie.

Une transaction atomique ne suffit pas à faire une publication

Une mise à jour SRP regroupe, dans un seul DNS Update, exactement une description d’hôte et éventuellement plusieurs descriptions et annonces de services. Les préconditions explicites de la RFC 2136 disparaissent ; le registraire applique les prédicats de la RFC 9665 : structure des enregistrements, cohérence des noms, clé commune, signature, bail obligatoire et absence de revendication concurrente.

L’atomicité évite un état partiellement inscrit. Elle ne garantit pas que la donnée a quitté le point d’entrée. Le registraire peut être un primaire caché. Les réponses aux clients peuvent venir de serveurs secondaires, d’un signataire ou d’un autre composant de publication. La preuve doit donc suivre l’événement d’acceptation vers le journal, la signature de zone, chaque autorité servante et la vue d’un résolveur.

Même une réponse DNS visible ne prouve pas l’application. SRV et TXT indiquent comment essayer le service ; A ou AAAA indique une adresse. Il faut encore authentifier le terminal selon les besoins du protocole puis effectuer une transaction sans effet destructif. SRP enregistre une annonce, il ne certifie pas le comportement annoncé.

Deux baux pour deux objets différents

Les enregistrements PTR, SRV, A, AAAA et TXT utilisent le bail de service, souvent de l’ordre de deux heures. La KEY peut conserver un KEY-LEASE beaucoup plus long, typiquement quatorze jours. Un appareil momentanément hors ligne cesse donc d’apparaître comme service tout en gardant sa revendication sur le nom.

Ce décalage est intentionnel. Il évite qu’une panne de quelques heures rende immédiatement le nom disponible à un autre équipement. Il faut toutefois le rendre visible : « service absent, nom réservé » n’est ni « service sain » ni « nettoyage en panne ».

Le TTL ouvre encore une autre horloge. L’expiration du bail commande au registraire de retirer l’enregistrement de ses réponses, mais elle ne rappelle pas une copie encore valide dans le cache d’un résolveur. Les preuves doivent conserver les valeurs accordées, l’instant de départ, les renouvellements, la vue autoritative et le TTL résiduel observé.

La frontière administrative précède la signature

Les mises à jour SRP n’ont pas d’autre sémantique d’autorisation que FCFS. Un registraire devrait donc refuser les sources extérieures à son domaine administratif. Sur TCP, la poignée de main limite l’usurpation hors chemin à condition de ne pas accepter sans contrôle équivalent des données TCP Fast Open. Sur UDP, les réseaux contraints dépendent du filtrage d’entrée et de la vérification de l’interface source.

La signature et le filtrage répondent à des questions différentes. La première lie le message à la clé ; le second limite l’accès au guichet. Les deux doivent figurer dans le reçu.

Le choix de zone est tout aussi décisif. Ouvrir SRP directement sur le domaine institutionnel permettrait à des demandeurs automatiques de revendiquer www, mail ou smtp. Une sous-zone dédiée et une liste de noms interdits limitent le pouvoir du premier arrivé. Les chemins DNS Update ordinaires doivent également être séparés : un autre identifiant autorisé à réécrire les mêmes RR peut rompre silencieusement la promesse faite à la clé SRP.

Enfin, service.arpa. est local, non un label de confiance mondial. Un résolveur extérieur au réseau peut ne pas connaître la vue correcte. Une application ne doit pas lui attribuer une identité PKI particulière. La provenance du nom et l’authentification du terminal restent des contrôles autonomes.

Le reçu défendable

Un dossier exploitable conserve le mode de découverte du domaine et du registraire, l’interface d’arrivée, le transport, le statut réel de validation TLS, les octets de la mise à jour, l’empreinte KEY, le résultat SIG(0), le graphe hôte-services, les conflits, les baux demandés et accordés, et la réponse brute.

Il ajoute ensuite la réplication, les réponses des autorités, l’observation récursive, l’authentification du terminal et le résultat applicatif. Aucun voyant ne doit emprunter l’autorité d’un autre.

Sources