Résumé

  • RFC 9952 attribue les deux octets 0x63 0x6f, soit co, à CoAP sur DTLS et permet leur emploi dans le paramètre SVCB alpn. Il précise aussi que RFC 7252 n’avait pas défini l’usage d’ALPN dans la poignée de main DTLS et que le nouveau texte n’ajoute pas les règles de RFC 8323.
  • Une inscription IANA coordonne un vocabulaire ; une annonce DNS expose un candidat ; seule la trace de ClientHello et ServerHello prouve une offre et une sélection. L’identité du pair, l’autorisation CoAP et le résultat applicatif restent encore en aval.

RFC 9952 accomplit un travail minuscule et utile. CoAP sur TLS possède déjà la valeur coap. Pour CoAP sur DTLS, le document choisit co, plus court, afin de limiter quelques octets dans des échanges où une fragmentation 6LoWPAN peut coûter cher. Il évite aussi de réutiliser le même identifiant pour deux couches de transport.

La tentation est d’élargir cette coordination : puisque co est enregistré, un endpoint CoAP sur DTLS devrait forcément l’envoyer ou le choisir. Le RFC ferme précisément cette porte. RFC 7252 n’avait pas défini l’extension ALPN dans sa poignée de main ; RFC 9952 ne change pas ce comportement et ne crée pas une machine d’état comparable à celle de RFC 8323.

Trois registres, trois autorités

La ligne IANA répond à une question de nommage. Elle fixe les octets qu’un profil ou une implémentation emploiera s’il utilise ALPN pour ce couple application-transport. Elle ne prouve ni support compilé, ni activation, ni offre, ni sélection.

Le DNS répond à une question de découverte. Une SVCB peut annoncer alpn=co, avec une cible et d’autres paramètres. Avant qu’un client ne s’y fie, il faut encore établir l’autorité de publication, l’état de validation, la fraîcheur du cache, le traitement des alias et la politique locale. Même une réponse DNSSEC valide ne prouve pas que le processus serveur a chargé la génération correspondante.

La poignée de main répond à une question de connexion. Selon RFC 7301, ClientHello porte une liste ordonnée ; le serveur choisit exactement une valeur offerte ou produit, dans le cas défini, l’alerte fatale no_application_protocol. Une configuration ne remplace pas cette observation.

Un reçu exploitable relie donc l’identité de connexion, les adresses, la version DTLS, la liste complète offerte, la sélection ou l’échec, l’heure et le point de capture. Il conserve aussi les nouvelles tentatives : un échange CoAP réussi sur une seconde connexion ne doit pas être attribué au premier ClientHello.

Deux octets gagnés ne garantissent aucun fragment économisé

La brièveté de co a une justification réelle. Mais la taille totale dépend des suites, groupes, partages de clés, signatures, cookies, extensions et certificats. La fragmentation DTLS n’est pas la fragmentation de liaison 6LoWPAN. MTU, pertes radio, retransmissions et limites d’amplification déterminent le résultat.

Pour affirmer un bénéfice, il faut comparer une configuration nommée : octets de ClientHello et ServerHello, fragments de liaison, retransmissions, durée et taux d’échec. La norme explique le choix du nom ; elle ne mesure aucune flotte.

Une sélection reste un reçu intermédiaire

Même la sélection capturée de co ne prouve pas l’identité attendue. Certificat ou clé publique brute, nom de référence, ancre de confiance et validité forment un autre contrôle. Elle ne prouve pas non plus qu’une requête CoAP a été comprise, autorisée ou exécutée.

Le chemin complet sépare : registre ; publication DNS ; choix du candidat ; offre ClientHello ; sélection ServerHello ; validation du pair ; échange CoAP ; autorisation de ressource ; effet applicatif ; résultat observé. Chaque étape peut être vraie quand la suivante échoue.

L’absence d’ALPN ne suffit pas davantage à condamner une connexion. RFC 9952 refuse une obligation universelle. Il faut identifier le profil local qui exige, permet ou ignore co, puis appliquer sa règle d’échec et de repli.

Cette discipline suit les notes de Lu Heng. La spécification commune reste minimale : un nom non ambigu pour l’interopérabilité. Les décisions futures restent aux endpoints qui supportent le risque. Les couches de réalité empêchent un symbole de registre d’emprunter la force d’une trace, puis une trace d’emprunter l’autorité d’une décision applicative. La primauté du code exécuté demande ce qui a réellement été chargé et échangé.

RFC 9952 est solide parce qu’il ne se proclame pas plus puissant qu’il ne l’est. Il donne un nom. Il ne fabrique pas le reçu.

Le registre d’exceptions fait partie de la preuve

Une migration réelle ne passe pas d’un état uniforme « sans co » à un état uniforme « avec co ». Certains capteurs gardent un firmware ancien ; certaines passerelles interrogent un résolveur différent ; certaines cibles SVCB restent en cache ; certains clients utilisent une adresse configurée et ne consultent jamais le DNS. Ces chemins ne sont pas des détails à cacher derrière un pourcentage de déploiement. Ils déterminent quel endpoint a pu connaître l’annonce, quel processus a pu produire l’offre et quel serveur a pu la sélectionner.

Le registre d’exceptions doit donc nommer le propriétaire, la population, la raison, la date d’expiration et le comportement de repli. Une date expirée n’est pas une fermeture : il faut une observation montrant que le dernier endpoint concerné a quitté l’ancien chemin. Tant qu’un chemin alternatif subsiste, ses connexions doivent conserver une identité propre et ses effets CoAP doivent pouvoir être attribués à cette connexion, non à l’intention générale du programme.

La preuve de livraison relie au minimum quatre artefacts : le binaire ou firmware contenant le support ; la configuration qui l’active ; la génération DNS visible par le client ; et une trace montrant l’offre puis la sélection. Aucun artefact ne remplace les autres. Un paquet récent peut charger une ancienne configuration ; un DNS récent peut conduire vers un listener ancien ; une trace correcte sur un canari ne décrit pas la population entière.

Cette séparation révèle aussi les frontières de responsabilité. L’équipe DNS peut prouver une publication cohérente sans prouver un ClientHello. L’équipe plateforme peut prouver l’activation sans prouver la sélection du serveur. L’équipe sécurité peut valider l’identité sans autoriser la ressource. L’équipe applicative peut constater un effet sans savoir si une tentative de repli l’a produit. Le rapport de mise en service doit conserver ces verdicts distincts avant de les réunir.

Sources