Résumé

  • Le projet individuel Oblivious CoAP fait passer une requête chiffrée par un mandataire qui connaît le client mais pas le contenu ; la passerelle connaît le contenu mais ne reçoit pas l’adresse du client.
  • Sa section 7.1 avertit que le mandataire ou un tiers peut rejouer la requête. Pour les opérations qui modifient un état, le serveur peut reconnaître le premier message grâce à enc et les suivants grâce à un compteur protégé.

Le facteur n’a pas besoin d’ouvrir une enveloppe pour la distribuer deux fois. Le projet Oblivious CoAP du 28 octobre bâtit une protection de l’origine autour d’un relais. Il lui laisse aussi la capacité très ordinaire de copier un paquet chiffré. Le lecteur final doit distinguer une seconde livraison d’une seconde décision.

CoAP sert aux échanges requête-réponse d’appareils contraints. La note cite des requêtes DNS sur CoAP, des diagnostics anonymes et des interrogations de répertoire de ressources. Le client chiffre la requête pour une passerelle au moyen de HPKE, puis l’envoie par un mandataire CoAP. Celui-ci voit l’adresse du client mais pas le texte protégé ; la passerelle déchiffre sans recevoir cette adresse. Cette séparation suppose que les deux rôles ne réunissent pas leurs journaux ou leur contrôle.

Le modèle rappelle Oblivious HTTP. Le projet ajoute une option CoAP capable de numéroter plusieurs messages liés au même contexte HPKE. Il requiert une passerelle volontaire, ce qui limite les usages possibles. Le point décisif pour un exploitant est ailleurs : le relais et même un adversaire extérieur peuvent rejouer les requêtes protégées, dit expressément la section 7.1.

Pour une méthode réellement sans effet de bord, si le serveur vérifie qu’un nouveau traitement reste sûr, le doublon peut être supporté. Pour une requête qui change un état, il faut repérer la répétition et arrêter son traitement lorsque le répéter serait inapproprié. La première requête porte une valeur d’encapsulation HPKE enc, ou son empreinte, qui peut servir d’identifiant de rejeu. Dans la suite d’un même échange, le compteur OCoAP count, protégé contre les modifications, peut être comparé à une fenêtre de rejeu liée au contexte reçu. Une option Echo protégée peut renforcer le contrôle.

Cette mémoire coûte au destinataire, pas au relais. Un rapport de diagnostic envoyé deux fois peut gonfler une statistique ; une commande qui modifie un état peut répéter son effet. La note ne mesure ni la durée de conservation des identifiants, ni l’espace nécessaire, ni le comportement après redémarrage. Une passerelle doit choisir les méthodes qu’elle juge sûres, garder les repères utiles et définir ce qu’elle fait si cette mémoire disparaît. Le chiffrement n’écrit pas cette politique à sa place.

Le registre IETF classe le texte comme projet individuel Standards Track, au stade I-D Exists. Le premier essai sérieux envoie une requête chiffrée, sa copie, puis un message lié ; on redémarre la passerelle entre les tentatives. On relève le nombre d’effets produits, les traces de rejeu survivantes et la capacité éventuelle des opérateurs à rapprocher origine et contenu.