Mon blog

Si vous utilisez Let's Encrypt (et tout le monde l'utilise, de nos jours), vous avez sans doute reçu les messages « Let's Encrypt Expiration Emails Update » qui vous préviennent que cette AC n'enverra plus de rappels que vos certificats vont bientôt expirer. C'est parce qu'un meilleur système est maintenant disponible, ARI (ACME Renewal Information). ARI permet à une AC utilisant le protocole ACME d'indiquer à ses clients des suggestions sur le renouvellement des certificats. Il est décrit dans ce RFC.

ACME est normalisé dans le RFC 8555 et est surtout connu via le succès de Let's Encrypt. Les certificats sont de courte durée (aujourd'hui trois mois mais ça va diminuer) et il faut donc les renouveler souvent. On peut le faire automatiquement via cron, ou bien analyser le certificat et renouveler quand sa date d'expiration approche. L'un des problèmes est que cela peut mener à ce que plusieurs demandes de renouvellement arrivent en même temps sur l'AC. Le pic d'activité qui en résulterait pourrait charger l'AC inutilement. L'idée est donc que ce soit le serveur ACME, l'AC, qui planifie les renouvellements, et pas le client ACME. Cela permettrait aussi des changements de planning, comme une réduction des durées de validité, ou bien une révocation.

Donc, ARI ajoute un nouvel URL à la description d'une AC, renewalInfo. Voici celui de Let's Encrypt (qui met en œuvre ARI depuis deux ans) :

% curl https://acme-v02.api.letsencrypt.org/directory
{
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "profiles": {
          …
    },
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.5-February-24-2025.pdf",
    …
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
  

Ce nouveau membre a été ajouté au registre IANA.

Et comment on obtient quelque chose à cet URL https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo ? On doit passer un identificateur du certificat. Il est formé par la concaténation de l'identifiant de l'AC et du numéro de série du certificat (pour garantir qu'il soit unique). Je passe sur les détails de construction (lisez la section 4 du RFC pour cela) mais ce petit script Python ari-make-path.py vous fait le calcul. Utilisons-le sur l'actuel certificat de ce blog :

% openssl x509 -text -in cert.pem
[Notez les valeurs]

% python ari-make-path.py 93:27:46:98:03:A9:51:68:8E:98:D6:C4:42:48:DB:23:BF:58:94:D2 00:06:7d:03:91:c6:49:b8:83:ba:e5:c6:da:8a:dc:be:4d:33:78
kydGmAOpUWiOmNbEQkjbI79YlNI.AAZ9A5HGSbiDuuXG2orcvk0zeA

% curl -i https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo/kydGmAOpUWiOmNbEQkjbI79YlNI.AAZ9A5HGSbiDuuXG2orcvk0zeA
…
retry-after: 21600
…
{
  "suggestedWindow": {
    "start": "2025-06-23T03:50:00Z",
    "end": "2025-06-24T23:00:50Z"
  }
}
  

Voilà, on a fait un URL en concaténant la valeur de renewalInfo avec celle obtenue à partir du certificat et on sait désormais quand est-ce que Let's Encrypt suggère de renouveler ce certificat. Le format de sortie est clair mais vous avez les détails dans la section 4.2. Les dates sont évidemment au format du RFC 3339. Au passage, la date d'expiration est le 24 juillet 2025 donc Let's Encrypt n'attend pas le dernier moment. (Comme le dit un commentaire dans le code source du serveur, « calculate a point 2/3rds of the way through the validity period (or halfway through, for short-lived certs) ».)

Le RFC précise qu'un membre explanationURL peut être ajouté mais Let's Encrypt ne le fait pas. Les membres possibles figurent dans un nouveau registre IANA, auquel on pourra ajouter de nouveaux membres, en fournissant une spécification (« Spécification nécessaire » du RFC 8126).

Et on utilise cet intervalle entre deux dates comment ? Le RFC recommande de choisir une date au hasard dans l'intervalle. Le client ACME ne doit pas dormir jusqu'à la date sélectionnée, il doit réessayer de temps en temps car l'AC a pu changer la date (c'est tout le principe d'ARI). Mais attention à respecter le Retry-After: (six heures, ici), cf. RFC 9110, section 10.2.3.

Notre RFC ajoute également un membre à la description d'une commande de certificat : replaces indique quel certificat on est censé remplacer. (En utilisant le même identificateur de certificat qu'indiqué plus haut.) Il a été ajouté au registre IANA.

ARI est mis en œuvre dans le serveur ACME de Let's Encrypt, Boulder. Regardez core/objects.go et notamment la fonction RenewalInfoSimple. Côté client, Lego, acmez et le CertMagic de Caddy ont ARI mais certbot ou dehydrated ne gèrent pas ARI. Si vous voulez vous y mettre, Let's Encrypt a écrit un guide d'intégration d'ARI.

Les API réseau, c'est très bien. Tout le monde en fait aujourd'hui, typiquement bâties au-dessus de HTTP. Mais il est parfois difficile de s'y retrouver parmi toutes les API. « Je suis sûr que l'INSEE avait une API pour faire ça mais où est-elle exactement et où est sa documentation ? La solution pour cela ? Les catalogues d'API, rassemblant nom, description, URL, etc, des API. Il ne reste plus qu'à trouver le catalogue… Ce RFC fournit pour cela un URL standard et un mécanisme de lien. Il fournit également un format standard pour écrire ce catalogue, bâti sur Linkset (RFC 9264, section 4.2).

Comme disait M. de la Palice, et comme le rappelle la section 1 du RFC, pour utiliser une API, il faut d'abord la découvrir. Cela veut dire apprendre son existence, quel va être l'URL à appeler (le endpoint), les paramètres à passer, quelles sont les conditions d'utilisation (gratuite ? nombre maximal de requêtes par jour ?), etc. Il existe des formats pour cela (le plus connu étant celui d'OpenAPI) mais il reste à trouver les fichiers de ce format. Pour faciliter cette tâche du développeur ou de la développeuse qui utilisera l'API, l'éditeur (publisher dans le RFC) qui publie l'API va fabriquer un joli catalogue, et le rendre lui-même découvrable. Un catalogue est une liste organisée des API offertes par une organisation donnée.

Première solution décrite par notre RFC (section 2) : un URL bien connu, et donc prévisible, https://www.example.net/.well-known/api-catalog (si l'éditeur est en www.example.net). Ces URL bien connus sont normalisés dans le RFC 8615. Évidemment, une redirection HTTP est possible. api-catalog a été ajouté au registre des URL bien connus.

Deuxième solution, un lien (section 3) api-catalog. Les liens, vous connaissez, et ils sont normalisés dans le RFC 8288. Ils peuvent se représenter de plusieurs façons, en HTML :

<!DOCTYPE HTML>
<html>
   <head>
         <title>Welcome to Example Publisher</title>
   </head>
   <body>
         <p>
          <a href="my_api_catalog.json" rel="api-catalog">
           Example Publisher's APIs
          </a>
         </p>
         <p>(remainder of content)</p>
   </body>
</html>

Ou bien en HTTP, dans la réponse :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Location: /index.html
Link: </my_api_catalog.json>; rel=api-catalog
Content-Length: 356    

  

Désormais, api-catalog figure dans le registre des types de liens.

Cette norme concerne la découverte du catalogue, mais aussi la syntaxe de son contenu. La section 4 du RFC donne des indications sur le contenu du catalogue, sa sémantique (inclure la politique d'utilisation, lien vers une spécification formelle, etc) et sa syntaxe, le format Linkset du RFC 9264. Des exemples figurent dans l'annexe A du RFC mais vous pouvez aussi regarder le catalogue des mes API (en construction). Voici le premier exemple de catalogue donné dans le RFC, utilisant les relations du RFC 8631 :

{
    "linkset": [
    {
      "anchor": "https://developer.example.com/apis/foo_api",
      "service-desc": [
        {
          "href": "https://developer.example.com/apis/foo_api/spec",
          "type": "application/yaml"
        }
      ],
      "service-doc": [
        {
          "href": "https://developer.example.com/apis/foo_api/doc",
          "type": "text/html"
        }
      ],
      "service-meta": [
        {
          "href": "https://developer.example.com/apis/foo_api/policies",
          "type": "text/xml"
        }
      ]
    },
    {
      "anchor": "https://developer.example.com/apis/bar_api",
      "service-desc": [
        {
          "href": "https://developer.example.com/apis/bar_api/spec",
          "type": "application/yaml"
        }
      ],
      "service-doc": [
        {
          "href": "https://developer.example.com/apis/bar_api/doc",
          "type": "text/plain"
        }
      ]
    }
  ]
}
  

D'autres formats que Linkset sont possibles (mais Linkset doit être présent), par exemple via la négociation de contenu. Quelques formats possibles cités par le RFC :

• APIs.json,
• RESTDesc,
• HAL,
• WebAPI.

Ce catalogue peut, et ce serait souhaitable, être écrit automatiquement par le cadriciel qu'on utilise pour développer ses API.

Et, sinon, où est-ce qu'on publie cette API ? La méthode recommandée (section 5) est de la publier à plusieurs endroits. Si on gère www.example.net et que les URL des API sont en api.example.com, le RFC recommande de les publier aux deux endroits. Rappelez-vous que les redirections HTTP sont permises, donc vous pouvez n'avoir qu'un seul exemplaire du catalogue, ce qui simplifie sa maintenance. Car, puisqu'on parle de maintenance, un gros défi sera clairement de garder ce catalogue à jour au fur et à mesure de l'évolution des API… (La section 8, sur la sécurité, revient sur ce problème.)

Je n'ai pas trouvé d'exemple réel dans le Web, même chez Vodafone, où travaille l'auteur. Mais j'ai fait un catalogue pour mes propres API. En l'absence d'outils de test et de validation pour les catalogues, il a peut-être quelques erreurs. (Si vous lisez la section 2 du RFC, vous verrez que mon serveur HTTP ne répond pas aux requêtes HEAD avec un lien dans l'en-tête, un Link:. Il devrait.)

La cryptographie post-quantique vise à développer des algorithmes de cryptographie qui résistent à des ordinateurs quantiques. Mais ces algorithmes sont relativement récents et peuvent avoir des faiblesses, voire des failles, que la cryptanalyse classique pourra exploiter. La tendance actuelle est donc aux protocoles et formats hybrides, combinant algorithmes classiques et post-quantiques. Ce RFC spécifie la terminologie de ces protocoles hybrides.

On peut aussi dire AQ, pour après-quantique car le sigle anglophone PQ de post-quantum peut faire drôle en France. D'ailleurs, les termes à utiliser (post-quantique ? résistant au quantique ?) ont fait l'objet de chaudes discussions dans le groupe de travail IETF.

Le point de départ de tout le tintouin autour de l'après-quantique, c'est l'algorithme de Shor. Conçu pour les calculateurs quantiques, et donc inutilisable encore aujourd'hui, il permet de résoudre des problèmes mathématiques qu'on croyait difficiles, comme la décomposition en facteurs premiers (qui est derrière RSA) ou le logarithme discret (qui est derrière ECDSA). Le jour, qui n'est pas encore arrivé, où on aura des CRQC (Cryptographically-Relevant Quantum Computer, un calculateur quantique qui puisse s'attaquer à des problèmes de taille réelle, et pas juste faire des démonstrations), ce jour-là, la cryptographie classique, ou traditionnelle, aura un problème.

Les CRQC sont loin dans le futur, un lointain dont il est très difficile d'estimer la distance. Comme on ne sait pas quand les CRQC seront disponibles, et que certains secrets qu'on chiffre maintenant devront rester secrets pendant de nombreuses années, il est prudent de travailler dès maintenant aux algorithmes AQ, après-quantique, ceux pour lesquels on ne connait pas d'algorithme (quantique ou classique) pour les casser. Ce travail a effectivement commencé depuis des années et on a déjà des algorithmes AQ normalisés comme ML-KEM (ex-Kyber). Notez toutefois qu'aucune norme IETF n'a encore été publiée en intégrant ces algorithmes, mais le travail est en cours, entre autres au sein du groupe de travail pquip.

Mais remplacer complètement les algorithmes traditionnels par les algorithmes AQ n'est pas forcément satisfaisant. Au contraire de RSA et ECDSA, testés au feu depuis longtemps et qui ont toujours résisté, les algorithmes AQ peuvent sembler un peu jeunes. Que se passerait-il si un·e cryptanalyste cassait un de ces algorithmes ? Pour limiter les dégâts, on envisage d'utiliser des mécanismes hybrides, combinant cryptographie classique (pré-quantique) et après-quantique. Ainsi, un chiffrement hybride verrait le texte en clair chiffré par un mécanisme classique puis par un mécanisme après-quantique. Une signature hybride se ferait en mettant deux signatures et en vérifiant ensuite que les deux sont valides. Cette méthode « ceinture et bretelles » est utilisée par exemple dans le RFC 9370 ou dans les Internet-Drafts draft-ietf-tls-hybrid-design, draft-ietf-lamps-pq-composite-kem ou draft-ietf-lamps-cert-binding-for-multi-auth. On peut aussi consulter la FAQ du NIST (« A hybrid key-establishment mode is defined here to be a key establishment scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes. ») ou bien le document ETSI TS 103 744 nommé « Quantum-safe Hybrid Key Exchanges ». Attention toutefois avec cette terminologie car l'adjectif « hybride » est également souvent utilisé en cryptographie pour désigner la combinaison d'un algorithme de cryptographie asymétrique avec un algorithme de cryptographie symétrique (quand on crée une clé de session échangée via de la cryptographie asymétrique puis qu'on chiffre les données avec cette clé et de la cryptographie symétrique ; c'est ce que font TLS et OpenPGP, par exemple). C'est le sens qu'utilisent les RFC 4949 et RFC 9180, par exemple. Notre RFC 9794 note que ces deux usages du terme « hybride » vont certainement prêter à confusion mais qu'il n'y avait pas trop le choix : chaque usage était déjà solidement installé dans un milieu particulier. Essayer de promouvoir un autre terme pour la cryptographie après-quantique, comme « double algorithme » ou « multi algorithme » était sans doute voué à l'échec.

Passons maintenant aux définitions. Je ne vais pas les reprendre toutes mais donner quelques exemples. La section 2 du RFC commence par les mécanismes de base et d'abord, mécanisme hybride traditionnel / post-quantique (post-quantum traditional hybrid scheme, ou PQ/T), un mécanisme qui combine la cryptographie existante et celle du futur. On peut aussi simplifier en disant juste mécanisme hybride. Il y a aussi :

• Multi-algorithme, qui est plus large qu'hybride puisqu'il inclut les mécanismes ayant deux algorithmes traditionnels ou deux algorithmes après-quantique.
• Composé (composite), qui désigne les mécanismes hybrides où le mécanisme est exposé aux couches supérieures sous forme d'une interface unique (ce qui est évidemment plus simple et plus sûr pour le ou la programmeur·se).

Ensuite, on grimpe d'un niveau (section 3 du RFC), avec les éléments, qui sont les données en entrée ou en sortie d'un processus cryptographique. Quand on dit « l'algorithme X prend en entrée un texte en clair et une clé secrète et produit un texte chiffré », le texte en clair, la clé et le texte chiffré sont des éléments. Dans le mécanisme hybride décrit dans draft-ietf-tls-hybrid-design, il y a deux clés publiques, qui sont deux éléments. Un élément peut à son tour être composé de plusieurs éléments.

On peut maintenant utiliser tout cela pour faire des protocoles (section 4). Un protocole hybride PQ/T est, comme vous vous en doutez, un protocole qui utilise au moins deux algorithmes, un classique et un après-quantique. C'est ce qui est proposé dans draft-ietf-tls-hybrid-design. Ce dernier est même composé (dans le mécanisme de désignation de la clé, le KEM). Alors que le mécanisme du RFC 9370 est hybride mais pas composé (on fait un échange de clés classique et un KEM après-quantique).

Les noms des services de sécurité qu'on souhaite utiliser vont de soi (section 5) : confidentialité hybride PQ/T (confidentialité assurée par un mécanisme hybride traditionnel/après-quantique) et authentification hybride PQ/T.

Idem pour les certificats (section 6). Un « certificat hybride PQ/T » contient au moins deux clés publiques, une pour un algorithme traditionnel et une pour un algorithme après-quantique (alors que le certificat traditionnel et le certificat après-quantique ne contiennent qu'un seul type de clé publique, comme c'est le cas du certificat décrit dans draft-ietf-lamps-dilithium-certificates).

Et merci à Magali Bardet pour sa relecture mais, bien sûr, les erreurs sont de moi et moi seul.

Traditionnellement, les registres de noms de domaine publiaient toutes les informations des sous-domaines avec la même durée de vie maximale (TTL : Time To Live). Certain·es client·es demandent à pouvoir choisir un TTL plus court (ou, parfois, plus long) et ce RFC décrit comment faire cela avec le protocole EPP.

Cet EPP, normalisé dans les RFC 5730 et suivants, est aujourd'hui le plus utilisé par les gros registres pour recevoir les commandes de leurs BE. (Cf. cet article de l'Afnic.) Tel que normalisé dans le RFC 5731, EPP ne permet pas, lors de la création d'un nom de domaine, de spécifier le TTL des enregistrements NS (NameServer) qui seront publiés. Prenons l'exemple de l'enregistrement d'un .fr. Le ou la titulaire va sur l'interface Web de son BE, réserve le nom cyberstructure.fr, le BE transmet la demande de création en utilisant EPP et le registre publie ensuite dans le DNS les informations de délégation, ici récupérées avec dig :

% dig @d.nic.fr cyberstructure.fr NS    
…
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
…
;; AUTHORITY SECTION:
cyberstructure.fr.	3600 IN	NS puck.nether.net.
cyberstructure.fr.	3600 IN	NS fns2.42.pl.
cyberstructure.fr.	3600 IN	NS ns2.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS ns4.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS ns2.afraid.org.
cyberstructure.fr.	3600 IN	NS fns1.42.pl.
cyberstructure.fr.	3600 IN	NS ns1.bortzmeyer.org.
…
  

À aucun moment, la·e titulaire ou le BE n'a spécifié de TTL (les 3 600 secondes), il a été choisi par le registre seul. Certain·es titulaires peuvent pourtant avoir des préférences différentes. (Je rappelle que la notion de TTL est définie rigoureusement dans le RFC de terminologie DNS, le RFC 9499, voir sa section 5.)

Si vous voulez creuser ce concept de délégation, l'article de l'Afnic sur DELEG l'explique dans sa première partie.

L'exemple ci-dessus montrait les enregistrements NS (NameServer) mais ce problème concerne aussi les DS (RFC 9364), la colle et les éventuels DNAME (par exemple pour mettre en œuvre le RFC 6927).

Ce RFC normalise une extension à EPP pour permettre au client (le BE) d'indiquer le TTL souhaité pour la délégation. (Ce qui ne signifie pas que le registre satisfera ce souhait, lisez plus loin.) Plus précisément, il étend les classes (mappings) EPP pour les noms de domaine (RFC 5731) et pour les serveurs de noms (RFC 5732), les seules classes dont les données se retrouveront dans le DNS (rappelez-vous qu'EPP n'est pas limité aux noms de domaine, c'est un protocole d'avitaillement générique).

La section 1.2 du RFC contient les informations essentielles. D'abord, l'espace de noms urn:ietf:params:xml:ns:epp:ttl-1.0 (enregistré à l'IANA), qui identifie cette extension (le RFC utilise l'alias ttl mais rappelez-vous qu'en XML, c'est l'espace de noms qui compte, l'alias est choisi par l'auteur du document XML). Ensuite, l'élément <ttl:ttl> (donc, en complet, {urn:ietf:params:xml:ns:epp:ttl-1.0}ttl), qui peut être ajouté aux demandes EPP ou aux réponses. Parmi ses attributs :

• for (le seul qui soit obligatoire) indique le type de données DNS auxquelles l'élément s'applique (uniquement des types qui jouent un rôle dans la délégation, NS, DS, DNAME, A et AAAA, ainsi que la valeur spéciale custom, qu'il faut compléter avec un attribut custom qui suit l'expression rationnelle de la section 3.1 du RFC 6895, et évidemment utilise un type enregistré),
• min (uniquement dans les réponses) qui indique la valeur minimale que le serveur (donc le registre) accepte (le registre est toujours libre de sa politique et peut refuser une valeur trop basse ou trop haute, répondant avec le code d'erreur EPP 2004, Parameter value range error),
• max, la contrepartie de min, avec les mêmes propriétés,
• default, qu'on ne trouve également que dans les réponses, et qui permet de connaitre la valeur qu'utiliserait le serveur si le client ne demande rien de spécifique.

L'élément <ttl:ttl> a pour contenu une valeur en secondes. Si cette valeur est vide, le serveur prendra la valeur par défaut (mais autant ne pas mettre d'élément <ttl:ttl> dans ce cas).

L'extension de ce RFC décrit des possibilités mais le registre, qui gère le serveur EPP, reste libre de ne pas tout accepter. Par exemple, il peut refuser l'utilisation de l'attribut custom, ou bien la restreindre à certains types (et, si le client demande quand même, répondre avec le code d'erreur EPP 2306 Parameter value policy error). Les types qui ont une syntaxe privilégiée (pas besoin de l'attribut XML custom) sont ceux qu'on peut actuellement trouver au-dessus de la coupure de zone (section 7 du RFC 9499).

Vous avez noté que, dans les types qui ont une syntaxe privilégiée dans ce RFC, il y a les types pour les adresses IP. Ils sont utilisés pour la colle DNS (section 7 du RFC 9499), si le serveur EPP met en œuvre la classe EPP pour les serveurs de noms (RFC 5732).

Un deuxième élément XML est spécifié par ce RFC, <ttl:info>, qui sert à demander ou à indiquer des informations sur la politique du serveur (voir des exemples plus loin).

La section 2 décrit dans quelles commandes EPP on peut ajouter les nouveaux éléments. Je ne vais pas toutes les détailler, juste montrer quelques exemples du XML envoyé et des réponses. Ainsi, ici, le client va utiliser la commande <epp:info> pour se renseigner sur la politique du serveur :

…
   C:     <info>
   C:       <domain:info
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:         <domain:name>example.com</domain:name>
   C:       </domain:info>
   C:     </info>
   C:     <extension>
   C:       <ttl:info
   C:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
   C:         policy="false"/>
   C:     </extension>
   …

  

Et la réponse du serveur :

…
   S:   <response>
   S:     <result code="1000">
   S:       <msg>Command completed successfully</msg>
   S:     </result>
   S:     <resData>
…
   S:         <domain:name>example.com</domain:name>
   S:         <domain:status s="ok"/>
…
   S:     </resData>
   S:     <extension>
   S:       <ttl:infData
   S:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
   S:         <ttl:ttl for="NS">172800</ttl:ttl>
   S:         <ttl:ttl for="DS">300</ttl:ttl>
   S:       </ttl:infData>
…
   S:   </response>
…

  

Le serveur indique que le TTL des enregistrements NS sera de deux jours. Sinon, vous avez repéré le policy="false" ? S'il avait été à true, le serveur aurait renvoyé l'information sur sa politique pour tous les types d'enregistrements DNS (section 2.1.1.2).

Créons maintenant un nom de domaine en spécifiant un TTL :

   C:   <command>
   C:     <create>
   C:       <domain:create
   C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:         <domain:name>example.com</domain:name>
   C:         <domain:ns>
   C:           <domain:hostObj>ns1.example.com</domain:hostObj>
   C:           <domain:hostObj>ns1.example.net</domain:hostObj>
   C:         </domain:ns>
   C:       </domain:create>
   C:     </create>
   C:     <extension>
   C:       <ttl:create
   C:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
   C:         <ttl:ttl for="NS">172800</ttl:ttl>
   C:         <ttl:ttl for="DS">300</ttl:ttl>
   C:       </ttl:create>
   C:     </extension>
   C:   </command>
   C: </epp>

    

Cela marcherait aussi dans un <domain:update>, pour changer les TTL.

Je l'ai déjà dit plusieurs fois, la demande du client ne va pas forcément être honorée par le serveur. La section 3 de notre RFC détaille l'interaction entre cette demande et la politique du serveur (donc du registre). Ainsi, le serveur peut limiter les types d'enregistrement DNS auxquels ces commandes s'appliquent, par exemple en n'acceptant de changer le TTL que pour les DS (d'où l'intérêt des demandes avec policy=…, pour savoir à l'avance).

D'autre part, le TTL des enregistrements publiés peut changer en dehors d'EPP, par une action du registre. Auquel cas, le registre (section 4) peut gentiment prévenir ses clients par le système de messagerie du RFC 8590.

La possibilité pour le client d'indiquer un TTL souhaité a aussi des conséquences opérationnelle (section 5). Ainsi, des TTL courts vont accroitre la charge sur les serveurs faisant autorité puisque les résolveurs auront besoin de demander plus souvent, les expirations se rapprochant. Souvent, les utilisateurs veulent des TTL courts, pour la réactivité, et n'ont pas conscience des conséquences, notamment en terme d'accroissement du trafic, d'autant plus que l'utilisation des serveurs DNS faisant autorité est gratuite pour eux. C'est pour cela que le registre peut fixer des valeurs minimales (et maximales, pour traiter d'autres problèmes) aux TTL souhaités par le client.

Une erreur parfois commise est de penser qu'un changement du TTL (via une commande EPP <epp:update>) va se voir instantanément. Mais, en fait, les informations, avec l'ancien TTL, sont encore dans la mémoire de plusieurs résolveurs. Il est donc recommandé de planifier les changements à l'avance, en tenant compte de cette mémorisation (section 5.2 du RFC). D'ailleurs, la politique du registre aussi peut changer, et les TTL par défaut, ainsi que les valeurs maximales et minimales, sont susceptibles d'être modifiées (un registre sérieux va informer ses utilisateurices de ces changements mais parfois, c'est oublié).

Un gros morceau de notre RFC est consacré à la sécurité (section 6) car les TTL ont une influence sur ce sujet. Premièrement, le fast flux (changement rapide des données de délégation DNS, cf. RFC 9499, section 7). Des malveillants utilisent cette technique pour rendre l'investigation numérique plus difficile et pour échapper à certaines règles de filtrage (voir le rapport SAC-025 du SAAC). Un TTL court peut faciliter ce changement rapide. Le rapport du SAAC suggère un TTL minimum de 30 minutes et/ou de limiter le nombre de changements qu'on peut faire par jour.

Si un malveillant réussit à obtenir les secrets qui lui permettent de soumettre des demandes de modification (au passage, pensez à activer l'authentification à plusieurs facteurs), il mettra sans doute des TTL très élevés pour que son détournement dure plus longtemps. D'où l'intérêt d'une valeur maximale pour les TTL.

Notre extension à EPP pour les TTL figure désormais dans le registre IANA des extensions et sa syntaxe complète, si vous êtes curieux·se, figure dans la section 8 (au format des schémas XML). Question mises en œuvre, vous en trouverez au moins deux, dans le SDK de Verisign et dans le logiciel Pepper (plus exactement dans la bibliothèque qu'il utilise, Net::EPP).

C'est un passionnant livre d'histoire de la communication et des médias que le résultat de la recherche menée par l'auteur sur la rubrique « La clinique des rumeurs », publiée par le Boston Herald pendant la Deuxième Guerre mondiale. Ce premier essai de fact-checking, comme on ne disait pas encore à l'époque, posait déjà toutes les questions liées à la vérification des informations, et à l'attitude à avoir face à la propagande de l'adversaire.

Le contexte est rude : les États-Unis sont en guerre. On fait des recherches actives sur les meilleurs moyens de propagande (cf. le livre « Le cercle démocratique »). Le pays est divisé (les relais de la propagande nazie comme Lindbergh s'exprimaient encore librement il y a peu), le racisme est fort et limite l'enthousiasme de certains à combattre. La guerre est un terrain fertile pour la paranoïa. On voit des espions partout et certains estiment que l'Axe pourrait sérieusement affaiblir ses ennemis en lançant des rumeurs. Un groupe de gens a l'idée de créer une rubrique dans un journal peu connu, le Boston Herald, et la baptise Rumor clinic, opération qui aura un certain succès et suscitera des imitateurs. Chaque article suit le plan {exposition d'une rumeur, démenti officiel}. Par exemple, une rumeur dit que des milliers de cadavres de marins étatsuniens ont été retrouvé sur une plage de Long Island, victimes des sous-marins allemands. Une autre que le sang donné par les citoyens noirs pour les hôpitaux militaires faisait que, une fois donné à des soldats blancs blessés, les receveurs auraient des enfants noirs. L'auteur du livre a épluché les numéros du journal et retrace l'histoire de cette « clinique des rumeurs » et des innombrables débats qui ont accompagné cette expérience, avant que la « clinique » ne soit fermée, avant même la fin de la guerre, victime de ses propres défauts et de rivalités bureaucratiques entre services étatiques, certains soutenant le projet et d'autres le combattant.

Pascal Froissart n'est pas tendre avec la clinique des rumeurs (comparez avec l'article bien plus favorable de Wikipédia). Rumeurs non sourcées (peut-être même inventées par les journalistes ?), indifférence face au risque que citer une rumeur pourrait lui donner de l'importance, vérification des faits limitée à citer des autorités, souvent militaires (pas la source la plus fiable pendant une guerre !), zéro enquête journalistique, appels à la vigilance citoyenne, malgré le risque que cela tourne à la chasse aux sorcières (surtout quand on sait ce qui s'est produit après la guerre…), vision binaire des faits (il n'y a que le mensonge et la vérité et rien entre les deux), absence de recherche sérieuse sur le phénomène social de la rumeur (bien qu'un des plus ardents promoteurs du projet soit un chercheur en psychologie). Ces défauts sont d'ailleurs toujours d'actualité dans certains discours anti « fake news », qui considèrent que seule la parole officielle est valable et que la vérité est forcément binaire.

On croise dans ce livre de nombreux personnages fascinants, dont le rôle réel était souvent masqué par le brouillard de la propagande. Ainsi, je ne connaissais pas la journaliste et militante antiraciste Frances Sweeney dont l'auteur estime qu'elle n'a pas eu de rôle réel dans la clinique des rumeurs.

Je divulgâche : on ne sait pas réellement si ces rumeurs étaient organisées par l'Axe. La clinique des rumeurs donnait souvent dans le complotisme, affirmant que tout propagateur de rumeur était un agent ennemi, et cela s'étendait aux ouvrières dénonçant les profits des industries de l'armement. Mais cela n'a jamais été prouvé. De façon amusante, l'OSS a recruté un ancien de la clinique des rumeurs pour aller propager des rumeurs chez l'ennemi (avec un succès mitigé).

Une lecture passionnante et très utile, dans un monde où les guerres et les menaces de guerre servent souvent, comme d'habitude, à faire taire les voix dissidentes, et où le mensonge est largement propagé, aussi bien par le ridicule complotiste de comptoir que par le président des États-Unis.

Dans le protocole de routage BGP, les annonces de routes sont marquées avec l'AS d'origine et avec les AS qui ont relayé l'annonce. Dans ce chemin des AS, on pouvait indiquer un ensemble d'AS, l'AS_SET (ainsi que l'AS_CONFED_SET). C'était déconseillé depuis le RFC 6472 et ce nouveau RFC 9774 l'interdit désormais. Le but est de simplifier BGP et notamment ses mécanismes de sécurité. Il faut maintenant forcément indiquer une suite ordonnée d'AS, une AS_SEQUENCE.

Ces AS_SET (et les AS_CONFED_SET du RFC 5065 mais je vais passer rapidement sur les confédérations) sont spécifiés par le RFC 4271, sections 4.3 et 5.1.2. Attention à ne pas confondre avec les objets de type as-set des bases des RIR comme, par exemple, celui de l'Afnic.

Un des inconvénients de ces AS_SET est que, puisqu'un ensemble n'est pas ordonné, il n'est pas évident de déterminer l'AS d'origine, le premier AS, ce qui est pourtant nécessaire pour la sécurité (ROV ou Route Origin Validation, cf. RFC 6811).

Pourquoi mettait-on des AS_SET alors ? Parce que c'est utile lorsqu'on effectue de l'agrégation de routes. L'agrégation, spécifiée dans les sections 9.1.2.2 et 9.1.4 du RFC 4271 est le mécanisme par lequel un routeur rassemble plusieurs routes en une route plus générale. Si les routes originales venaient de plusieurs AS, on pouvait les rassembler en un AS_SET. Mais, évidemment, cela brouille l'information sur la vraie origine d'une route. C'est pour cela que les techniques de sécurisation de BGP, comme le BGPsec du RFC 8205 ne s'entendent pas bien avec les AS_SET.

La section 3 est la partie normative du RFC : désormais, une machine qui parle BGP ne doit plus utiliser d'AS_SET ou d'AS_CONFED_SET dans les chemins d'AS de ses messages de mise à jour de routes. Une machine qui reçoit ce genre de messages doit les traiter comme une erreur et retirer les routes (cf. RFC 7606). Les techniques de sécurisation comme ROV (RFC 6811) ou BGPsec (RFC 8205) considèrent toute annonce incluant des AS_SET comme invalide.

Sur l'agrégation, voyez par exemple cette réponse sur StackExchange. La procédure désormais suggérée pour en faire (section 5) est d'indiquer comme AS d'origine du préfixe agrégé l'AS qui a fait l'agrégation (en s'assurant bien qu'il y a un ROA - RFC 6482). Les annexes A et B donnent des exemples détaillés.

Il est frappant de constater que la majorité des documentations BGP des routeurs continue à mettre AS_SET et AS_SEQUENCE sur un pied d'égalité, alors que le RFC 6472 date de déjà 14 ans.

Le RFC note que les AS_SET sont peu utilisés, et parfois mal (un AS_SET ne comportant qu'un seul AS, ou bien ayant des numéros d'AS spéciaux…). Cherchons un peu. Je prends une RIB (Routing Information Base) complète sur RouteViews. Elle est au format MRT (Multi-Threaded Routing Toolkit, RFC 6396). Passons là à travers bgpdump, produisant un fichier texte. Comment trouver les AS_SET ? J'ai simplement lu le code source de bgpdump :

 if (space)
	    {
	      if (segment->type == AS_SET
		  || segment->type == AS_CONFED_SET)
		as->str[pos++] = ',';
	      else
		as->str[pos++] = ' ';
		}
  

OK, il y a des virgules entre les AS (et une autre partie du code montre que les AS_SET sont placés entre accolades). On peut alors chercher le fichier texte et trouver, par exemple, cette annonce :

TIME: 04/16/25 12:00:02
TYPE: TABLE_DUMP_V2/IPV4_UNICAST
PREFIX: 45.158.28.0/23
FROM: 12.0.1.63 AS7018
ORIGINATED: 04/15/25 06:11:28
ASPATH: 7018 3356 3223 {8262,34224} 201200
NEXT_HOP: 12.0.1.63
COMMUNITY: 7018:5000 7018:37232
  

L'annonce du préfixe 45.158.28.0/23, dont l'origine est l'AS 201200, est passée par l'AS 8262 ou bien le 34224, ou bien il y a eu agrégation de deux routes, chacune passée par un de ces deux AS (mais cela n'a pas été marqué). Sur un looking glass, on voit le passage par le 8262 uniquement :

Mon Apr 21 10:30:34.855 CEST
BGP routing table entry for 45.158.28.0/23
Paths: (3 available, best #2, not advertised to any peer)
  Path #1: Received by speaker 0
  174 3356 3223 8262 201200, (received-only)
    149.6.34.5 from 149.6.34.5 (38.28.1.70)
      Origin IGP, metric 17060, localpref 100, valid, external
      Community: 174:21100 174:22009
      Origin-AS validity: not-found
      …
    

Soit ce looking glass a reçu une autre annonce, soit son code n'affiche que l'un des AS de l'AS_SET.

Autre exemple, où l'AS_SET est à l'origine :

TIME: 04/16/25 12:00:04
TYPE: TABLE_DUMP_V2/IPV4_UNICAST
PREFIX: 67.204.16.0/22
FROM: 89.149.178.10 AS3257
ORIGINATED: 04/10/25 00:44:05
ASPATH: 3257 13876 {15255,396519,396895}
NEXT_HOP: 89.149.178.10
MULTI_EXIT_DISC: 10
AGGREGATOR: AS13876 67.204.31.4
COMMUNITY: 3257:4000 3257:8118 3257:50002 3257:50120 3257:51100 3257:51110

Là, il y a eu agrégation, par l'AS 13876, qui a placé un AS_SET. Vu par le looking glass :

   
Mon Apr 21 10:39:46.348 CEST
BGP routing table entry for 67.204.16.0/22
Paths: (3 available, best #2, not advertised to any peer)
  Path #1: Received by speaker 0
  174 3356 13876 {15255,396519,396895}, (aggregated by 13876 67.204.31.4), (received-only)
    149.6.34.5 from 149.6.34.5 (38.28.1.70)
      Origin IGP, metric 17060, localpref 100, valid, external
      Community: 174:21100 174:22009
      Origin-AS validity: not-found
    

Je ne suis pas sûr que tous les looking glass affichent correctement les AS_SET. Mais étant donné que notre nouveau RFC met les AS_SET à la poubelle, il ne servirait à rien de demander au développeur d'ajouter ce service. Ah, et mon bot fédivers qui lit la table BGP gère ça bien.

Les textes de loi (et assimilés : décrets, par exemple) ne sont pas évidents à trouver et donc à citer. Ce RFC crée un espace URN (RFC 8141), lex, pour pouvoir identifier les textes juridiques. S'il est largement adopté par les juristes (ce n'est pas gagné…), il facilitera les références aux textes légaux. Ainsi,urn:lex:fr:etat:loi:2011-03-22;2011-302 pourrait identifier la loi n° 2011-302 portant diverses dispositions d'adaptation de la législation au droit de l'Union européenne en matière de santé, de travail et de communications électroniques, par exemple (elle change entre autres le régime applicable aux noms de domaine).

Comme toujours avec les URN (RFC 8141) et avec les URI en général, le but est d'attribuer des identificateurs uniques désignant une source de loi. Cette source peut être une loi, un décret, un texte d'une autorité de régulation, un jugement, etc. En revanche, les opinions et commentaires des juristes ne sont pas prévus. Comme avec tous les URN, l'identificateur ne dépend pas de la localisation en ligne d'un document (c'est un URN, pas un URL), ou même d'ailleurs de si le document est en ligne ou pas. Le but est que l'identificateur soit unique, et stable sur le long terme.

Le projet est né en Italie, sur la base du projet NormeInRete, datant de 2001. Des projets similaires existent dans d'autres pays. (Voir le livre « Technologies for European Integration; Standards-based Interoperability of Legal Information Systems ». Au niveau européen, voir « Law via the Internet; Free Access, Quality of Information, Effectiveness of Rights ».) Au niveau mondial, on peut noter que le document « Access to Foreign Law in Civil and Commercial Matters » pronait « State Parties are encouraged to adopt neutral methods of citation of their legal materials, including methods that are medium-neutral, provider-neutral and internationally consistent. ». Un tel système d'identificateurs est évidemment d'autant plus indispensable que l'inflation législative fait qu'on dépend tout le temps de textes de lois, et qu'on a besoin de les référencer dans de nombreux contextes. Toute ambiguïté dans cette référence serait bien sûr très gênante.

En pratique, le problème n'est pas trivial. Le mécanisme pour créer ces identificateurs doit être assez rigide pour assurer l'interopérabilité mais en même temps assez souple pour s'adapter aux évolutions futures. Et il doit être décentralisé car il n'y a pas d'institution mondiale supervisant les lois de tous les pays et chaque pays (voire davantage, notamment dans les États fédéraux) a déjà un mécanisme d'identification des lois.

L'approche choisie est donc un système hiérarchique, indiquant successivement le pays (via son TLD, ou via un nom de second niveau comme un.org pour l'ONU qui, curieusement, n'utilise pas son .int), la juridiction émettrice et enfin le document. On ne change donc pas les systèmes existants et on n'oblige pas les juridictions locales à adopter un système radicalement différent. La référence locale du document suit donc un schéma qui dépend de la juridiction, schéma qu'il n'est pas prévu d'uniformiser. Ainsi, urn:lex:eu:commission:directive:2010-03-09;2010-19-EU sera un texte européen (le eu), émis par la Commission, plus précisément ce sera une directive, la 2010-19-EU (la directive « modifiant la directive 91/226/CEE du Conseil et la directive 2007/46/CE du Parlement européen et du Conseil afin de les adapter aux progrès techniques dans le domaine des systèmes antiprojections de certaines catégories de véhicules à moteur et de leurs remorques »). Et urn:lex:be:conseil.etat:decision:2024-08-29;260.536 sera une décision du Conseil d'État belge (demande l’annulation de « la décision de non-classement et de non-retenue de la candidature notifiée par la partie adverse le 14 mars 2022 à la partie requérante »). Pour un pays fédéral, on aura une indication de l'entité qui émet le texte, par exemple urn:lex:br;sao.paulo:governo:decreto précédera l'identificateur d'un décret de l'État de São Paulo. (Notez le point-virgule, certains caractères sont réservés pour séparer des sous-champs dans l'URN, cf. section 3.2.)

Il devrait y avoir dans le futur un registre (pas un registre IANA) des codes identifiants les juridictions (section 2.2) du RFC mais, en septembre 2024, il n'était pas encore créé. Sa politique d'enregistrement sera « Examen par un expert » (« Expert review » du RFC 8126). Même en cas de changement géopolitique (fusion de deux pays, par exemple), les codes ne sont jamais réattribués, puisque les URN doivent être stables sur le long terme.

Les URN n'ont pas de mécanisme de résolution standard. Si on veut, à partir d'un URN, accéder à une ressource en ligne, il faut une méthode spécifique à chaque espace sous les URN. Pour lex, il est envisagé d'utiliser le DNS, en transformant l'URN en un URL, contenant un nom de domaine (section 10 du RFC, commentée plus loin). C'est d'ailleurs pour faciliter la correspondance avec les noms de domaine que le RFC (à tort, à mon avis), déconseille (section 3.4) d'utiliser des caractères non-ASCII dans les URN lex et donc d'utiliser un système de correspondance, depuis la langue de la juridiction concernée (urn:lex:de:stadt.muenchen:rundschreiben:... au lieu de urn:lex:de:stadt.münchen:rundschreiben:...). Si c'est assez évident pour l'italien ou le français (ministère → ministere), cela va nécessiter des correspondances plus élaborées dans d'autres cas. Si c'est vraiment trop difficile, le RFC recommande d'utiliser Unicode et, si on utilise le DNS et qu'on fait une correspondance en nom de domaine, de se servir de Punycode.

Quant au nom des juridictions, le RFC recommande de ne pas utiliser d'abréviations (même si elles sont courantes dans les textes juridiques), car elles ne sont pas toujours cohérentes. Donc, ministere et pas min.. Toujours pour des raisons d'uniformité, les dates doivent être en ISO 8601. [Encore une mauvaise idée : contrairement à ce qu'on lit souvent, cette norme ne garantit pas un format unique, loin de là. Utiliser le RFC 3339 aurait été une meilleure idée. Mais, en fait, le RFC suggère un profil réduit de ISO 8601 donc, en pratique, cela devrait marcher.]

Parmi les pièges amusants, il y a le fait que certains textes sont issus de plusieurs juridictions. C'est le cas des traités internationaux, par exemple. Si l'Espagne et le Portugal signent un accord, doit-il être sous urn:lex:es ou bien urn:lex:pt ? La solution du RFC (section 5.5) est simple : le texte a plusieurs URN (deux dans l'exemple ibérique ci-dessus). D'autres cas peuvent d'ailleurs se produire où un texte légal a plusieurs URN donc il n'y a pas d'URL « canonique » pour un texte. La fonction URN → texte est sans ambiguïté mais il n'y a pas de fonction texte → URN.

Maintenant, un peu de bureaucratie (section 9). Si je veux enregistrer un ou plusieurs URN lex, quelle est la marche à suivre ? D'abord, trouver le code de juridiction (en général le TLD du pays) puis l'organisation (registrar dans le RFC) chargée de gérer ce code. (Rappelez-vous que cette infrastructure n'existe pas encore.) Ces organisations doivent être stables sur le long terme, si on veut assurer la stabilité des identificateurs. Ensuite, comme chacune de ces organisations a sa propre politique, il faut suivre la politique en question.

Bon, c'est bien joli d'avoir des identificateurs stables. Mais, de nos jours, la plupart des utilisateurices voudraient davantage. Ils voudraient de l'opérationnel : je mets (je tape, je copie/colle…) un identificateur dans un navigateur et pouf, j'ai une jolie page avec le texte de loi ainsi identifié. Pour que ce beau projet fonctionne, il faut un système de résolution (section 10), qui va prendre en entrée un URN dans l'espace lex et nous donner un identificateur de plus bas niveau, un URL, par exemple, utilisable par le logiciel pour récupérer un contenu. La conception d'un tel système n'est pas triviale, entre autres parce que certains des URN lex seront invalides, par exemple lorsqu'ils auront été fabriqués automatiquement ou semi-automatiquement à partir de références informelles.

La méthode proposée dans cette section 10 (mais rappelez-vous que, pour l'instant, tout cela n'existe que sur le papier) est de s'appuyer sur le DNS et plus précisément sur les enregistrements de type NAPTR (normalisés dans le RFC 3404). Cela passera par le nom (déjà créé, cf. section 12 du RFC) lex.urn.arpa :

% dig lex.urn.arpa NAPTR
…
;; ANSWER SECTION:
lex.urn.arpa.		86400 IN NAPTR 100 10 "" "" "" lex-nameserver.nic.it.

  

Du point de vue gouvernance, il est prévu que le CNR maintienne la racine du système, notamment le serveur lex-nameserver.nic.it mentionné plus haut (ne cherchez pas à l'interroger, il semble ne pas avoir de données encore). Quand tout cela fonctionnera, un URN lex sera traduit en un URL (RFC 3405), par exemple quand le Brésil aura mis en place son système, et envoyé au CNR les informations nécessaires, urn:lex:br:senado:… sera traduit via les NAPTR en https://lex.senado.gov.br/… qui sera ensuite utilisé, par exemple par un navigateur.

L'espace lex a été enregistré (section 12) dans le registre des espaces de noms pour les URN via cette demande.

Aujourd'hui, sur l'Internet, on n'utilise plus (ou, en tout cas, cela devrait être le cas) que des algorithmes de chiffrement AEAD (Authenticated Encryption with Associated Data). Ils assurent confidentialité et intégrité des données. Mais on peut être gourmand et vouloir en plus d'autres propriétés. Ce nouveau RFC classe ces propriétés et définit la terminologie.

Les algorithmes de chiffrement anciens, non-AEAD, assuraient la confidentialité, mais pas l'intégrité. Un méchant (ou un accident) pouvait modifier les données sans que ce soit détectable et le déchiffrement produisait ensuite un texte qui n'était pas le texte original. Bien sûr, s'il s'agissait d'un texte en langue naturelle, ou bien d'un texte dans un format structuré, l'utilisateurice pouvait parfois voir qu'il y avait eu un problème, puisque, avec certains modes de chiffrement, ielle ne récupérait que du n'importe quoi. Mais il serait souhaitable de détecter l'attaque (ou le problème) le plus tôt possible. Et il y a aussi des raisons de sécurité pour assurer confidentialité et intégrité en même temps. Sinon, certaines attaques (comme Poodle) sont possibles. Et il faut aussi compter avec le fait que les programmeurs peuvent se tromper s'ils doivent appliquer confidentialité et intégrité séparément (cf. RFC 7366).

Vérifier l'intégrité peut se faire avec une somme de contrôle avec clé (MAC), ou une technique équivalente mais l'AEAD fait mieux, en intégrant chiffrement et vérification de l'intégrité. Cela a plusieurs avantages, dont les performances (plus besoin de chiffrer et de calculer un MAC successivement) et, comme indiqué plus haut, la sécurité.

Dans la famille des normes de l'Internet, l'AEAD est décrit plus en détail dans le RFC 5116. À partir de la version 1.3 (normalisée dans le RFC 8446), TLS impose l'utilisation d'algorithmes AEAD. Même chose pour QUIC (RFC 9000). Parmi les algorithmes AEAD courants, on trouve AES-GCM et ChaCha20-Poly1305 (RFC 8439) mais aussi Aegis ou OCB (RFC 7253).

Au passage, je trouve que le terme en anglais, authenticated encryption et sa traduction en français, chiffrement authentifié, sont trompeurs. Le service qu'ils assurent n'est pas l'authentification telle qu'on peut la faire avec RSA ou ECDSA. Je préférerais qu'on parle de chiffrement intègre.

Tout cela est bien connu depuis des années. Mais l'appétit vient en mangeant et certaines utilisations bénéficieraient de services supplémentaires. Les algorithmes existants sont sûrs par rapport aux modèles de menace « traditionnels » mais il en existe d'autres, auxquels tous les algorithmes AEAD ne répondent pas forcément. Ces services supplémentaires, pour répondre à ces modèles de menace, existaient parfois, et parfois ont déjà été développés, mais des équipes différentes leur donnent des noms différents. D'où le projet d'unification de la terminologie de ce RFC 9771. Il présente les propriétés supplémentaires (en plus de la confidentialité et de l'intégrité, que tout algorithme AEAD fournit), des noms d'algorithmes qui les fournissent et des cas d'usage. Le but est que les futurs RFC normalisant des protocoles qui dépendent de ces propriétés utilisent le vocabulaire de notre RFC.

Les propriétés supplémentaires, au-delà de la confidentialité et de l'intégrité basiques, sont listées dans la section 4. Il y a deux catégories :

• Propriétés de sécurité, lorsque la propriété permet de parer certaines attaques,
• propriétés de mise en œuvre, lorsqu'elles permettent de meilleures implémentations,
• et, pour, voir si vous savez compter jusqu'à deux, il y a aussi une catégorie un peu fourre-tout, pour les propriétés qui ajoutent de nouvelles fonctions, mais je n'en parlerai pas plus ici (consultez l'annexe A du RFC).

Avant d'exposer les propriétés additionnelles, le RFC présente les traditionnelles, en suivant le même schéma (définition, exemples, éventuels synonymes, cas d'usage, lectures pour approfondir) : confidentialité et intégrité sont ainsi exposées. Passons ensuite aux choses sérieuses, avec les propriétés de sécurité supplémentaires.

D'abord, la sécurité face aux changements (blockwise security) : c'est le fait d'être sûr même quand un adversaire particulièrement puissant peut modifier le texte en clair en fonction de ce qui a déjà été chiffré. Tous les adversaires n'ont heureusement pas ce pouvoir mais cela peut arriver, par exemple lors du streaming. Ainsi, la famille Deoxys résiste à ce type d'attaque.

Ensuite, l'engagement complet (full commitment). C'est l'extrême difficulté à trouver deux jeux {clé, numnique, données en clair} qui donneront le même texte chiffré. Cela sert dans le message franking mais ne me demandez pas ce que c'est, lisez cet article. Ascon a cette propriété. Et, au passage, le AD de AEAD veut dire « données associées » (associated data, des méta-données ajoutées au message) et les « données en clair » incluent donc ces données associées.

La résistance aux fuites (leakage resistance) est une propriété des algorithmes cryptographiques (pas seulement AEAD) dont la sécurité ne diminue pas même si l'attaquant obtient des informations via un canal secondaire. Un exemple d'un tel canal secondaire est le temps de calcul (si l'attaquant peut le chronométrer et si l'algorithme n'est pas résistant aux fuites, l'attaquant pourra obtenir des informations sur la clé) ou bien la consommation électrique. Bien sûr, cela dépend de l'implémentation (essayer de faire tous les calculs en un temps constant, quelle que soit la clé) mais un algorithme résistant aux fuites est un algorithme qui ne dépend pas trop (mild requirement, dit le RFC) de son implémentation concrète pour être sûr. Cette propriété est particulièrement importante pour les machines que l'attaquant peut contrôler physiquement (cartes à puce, objets connectés) alors que mesurer le temps de calcul, et a fortiori la consommation électrique, d'un serveur Internet distant est une autre affaire. (Mais ça reste possible dans certains cas, notamment si l'attaquant est proche, par exemple chez le même hébergeur : voir l'article « Remote Timing Attacks Are Practical » ou bien la faille Hertzbleed.)

La sécurité multi-utilisateurs (multi-user security) est atteinte quand la sécurité décroit moins vite que linéairement avec le nombre d'utilisateurs (les algorithmes ont des limites quantitatives, cf. draft-irtf-cfrg-aead-limits). C'est indispensable pour des protocoles comme TLS, où plusieurs « utilisateurs » peuvent se retrouver sur la même session TLS. Des algorithmes comme AES-GCM ou ChaCha20-Poly1305 ont cette sécurité (si on ne dépasse pas les limites). Vous pouvez lire « The Multi-user Security of Authenticated Encryption: AES-GCM in TLS 1.3 » pour les détails.

Bien sûr, il fallait mentionner la propriété de résistance aux calculateurs quantiques (Quantum security). AEAD ou pas, un algorithme est résistant au quantique si on ne connait pas d'algorithme pour calculateur quantique capable de casser cet algorithme. Les algorithmes comme AES-GCM ou ChaCha20-Poly1305 sont ainsi résistants (au prix parfois d'une augmentation raisonnable de la taille de la clé). Cette résistance permet de faire face au cas où un indiscret stocke aujourd'hui des messages qu'il ne sait pas déchiffrer, en attendant qu'il dispose d'un calculateur quantique. Notez que si on fait face à un adversaire mieux armé, qui n'a pas seulement un calculateur quantique mais peut en plus accéder à l'état quantique de votre système de chiffrement, ça devient plus compliqué. Dans ce cas très futuriste, il faut passer à des algorithmes comme QCB (cf. « QCB: Efficient Quantum-Secure Authenticated Encryption »).

Tout cela, c'étaient les propriétés de sécurité des algorithmes, liés à la définition de ces algorithmes. Mais, en pratique, on n'utilise pas un algorithme mais une mise en œuvre de l'algorithme, réalisée dans un programme. La section 4.4 du RFC liste des propriétés souhaitables des mises en œuvre (en plus de la propriété évidente que le programme soit rapide), propriétés qui n'affectent pas la sécurité (que ce soit en bien ou en mal). Par exemple, on souhaite que le programme soit léger, au sens où il tourne sur des machines contraintes (en mémoire, en processeur, en énergie, etc). Le rapport du NIST « NISTIR 8114 - Report on Lightweight Cryptography » est une lecture intéressante à ce sujet.

On souhaite ensuite un programme qui puisse exploiter le parallélisme de la machine qui l'exécute. Si celle-ci a plusieurs processeurs et/ou plusieurs cœurs, il serait bon que le travail puisse être réparti entre ces cœurs. Des algorithmes comme le mode CBC ne permettent pas le parallélisme lors du chiffrement.

Autres propriétés souhaitables citées par le RFC : ne pas nécessiter un travail supplémentaire ou de nouvelles ressources quand on introduit une nouvelle clé, fonctionner en une passe unique sur les données, permettre de chiffrer un flux de données continu, sans attendre sa fin…

Merci beaucoup à Manuel Pégourié-Gonnard et Florian Maury pour une relecture détaillée avec plein de bonnes remarques. Comme toujours, les erreurs et approximations sont de moi, pas des relecteurs.

Un message HTTP est traditionnellement représenté comme du texte mais ce RFC spécifie une alternative, une représentation binaire d'un message.

À quoi ça sert ? L'un des buts est de faciliter la transmission de messages HTTP (requêtes ou réponses, cf. RFC 9110) par d'autres protocoles que HTTP. C'est ainsi que l'oblivious HTTP du RFC 9458 utilise ce format binaire. D'autre part, un format binaire a des chances d'être plus compact. (Le RFC dit aussi que cela permet l'application du chiffrement intègre, mais ce serait le cas aussi avec du texte, je trouve.) Et l'analyse d'un tel format est plus simple, avec moins de pièges que celle du format texte, qui mènent parfois à des failles de sécurité (voir par exemple la section 11 du RFC 9112). Comme vous le savez, les versions 2 et 3 de HTTP encodent déjà l'en-tête en binaire et leurs spécifications (RFC 9113 et RFC 9114) ont servi de base à ce nouveau RFC. Le nouveau format a le type message/bhttp (le format traditionnel étant message/http).

On peut encoder le message HTTP en binaire suivant deux modes. Le premier préfixe tous les éléments par leur longueur, ce qui est plus efficace. Le deuxième ne le fait pas, ce qui permet de commencer à encoder sans connaitre la longueur finale.

Notez bien que c'est la sémantique du message qui est encodée, pas sa représentation texte. Concrètement, cela veut dire qu'un message HTTP représenté en texte, traduit en binaire, puis re-traduit en texte ne sera pas identique au bit près.

Bon, mais c'est quoi un message HTTP ? La section 6 du RFC 9110 nous l'apprend. S'il peut être encodé de plusieurs manières, la vision abstraite du message est toujours la même : le message est une requête ou une réponse, s'il est une requête, il y a une méthode (GET, PUT, etc) et la ressource demandée, s'il est une réponse, un code de retour (comme le fameux 404), puis dans les deux cas, un en-tête (avec les champs comme Host: ou Content-Type:), un corps (qui, comme l'en-tête, peut être vide), un pied (en général absent), et parfois du remplissage. Dans notre encodage en binaire, le fait que le message soit une requête ou une réponse sera indiqué par le framing indicator, qui vaut 0 dans le premier cas et 1 dans le second, pour le mode à longueur connue, et 2 ou 3 pour le mode à longueur pas connue à l'avance (section 3.3).

Le reste de ce que vous devez savoir sur ce format est dans les sections 3.4 (pour les requêtes) et 3.5 (pour les messages). Mais on va voir cela avec des exemples (la section 5 du RFC en contient plusieurs) et du code qui tourne.

Puisque ce format binaire est, à l'heure actuelle, surtout utilisé par oblivious HTTP, on va se tourner vers les mises en œuvre de cette technique. Prenons ohttp. Il est écrit en Rust. Les instructions de compilation marchent bien, je les résume ici (c'était pour une machine Arch) :

export workspace=$HOME/tmp
sudo apk add mercurial gyp ca-certificates coreutils curl git make mercurial clang llvm lld ninja-build 
cd $workspace
git clone https://github.com/martinthomson/ohttp.git
git clone https://github.com/nss-dev/nss ./nss
hg clone https://hg.mozilla.org/projects/nspr ./nspr
export NSS_DIR=$workspace/nss
export LD_LIBRARY_PATH=$workspace/dist/Debug/lib
cd ohttp
cargo build
cargo test

Et commençons par encoder une simple requête (je vous rappelle que la section 5 du RFC, et le répertoire examples/ de ohttp contiennent d'autres exemples, y compris plus complexes) :

% cat request-1.txt 
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.framasoft.fr
   
% ./ohttp/target/debug/bhttp-convert < ./request-1.txt > request-1.bin 

(Attention, le fichier texte doit avoir des fins de ligne CR-LF, comme le prescrit la norme HTTP et il doit y avoir une ligne vide à la fin. Si vous éditez avec emacs sur une machine Unix, C-x RET f puis dos). Regardons le fichier binaire produit (on aurait aussi pu utiliser od, ou bien emacs avec l'excellent mode hexl-mode) :

% xxd request-1.bin 
00000000: 0003 4745 5405 6874 7470 7300 0a2f 6865  ..GET.https../he
00000010: 6c6c 6f2e 7478 7440 560a 7573 6572 2d61  llo.txt@V.user-a
00000020: 6765 6e74 3463 7572 6c2f 372e 3136 2e33  gent4curl/7.16.3
00000030: 206c 6962 6375 726c 2f37 2e31 362e 3320   libcurl/7.16.3 
00000040: 4f70 656e 5353 4c2f 302e 392e 376c 207a  OpenSSL/0.9.7l z
00000050: 6c69 622f 312e 322e 3304 686f 7374 1077  lib/1.2.3.host.w
00000060: 7777 2e66 7261 6d61 736f 6674 2e66 7200  ww.framasoft.fr.
00000070: 00                                       .

Le premier octet est le framing indicator, encodé selon la section 16 du RFC 9000 (dans le source de ohttp, regardez bhttp/src/rw.rs). Il vaut zéro, indiquant une requête de longueur connue. Le deuxième octet, de valeur trois, indique la longueur de la méthode HTTP, puis suivent les octets de cette méthode (G E T).

Encodons ensuite une réponse :

% cat response-1.txt 
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Content-Length: 51
Content-Type: text/plain

Hello World! My content includes a trailing CRLF.

% ./ohttp/target/debug/bhttp-convert < ./response-1.txt > response-1.bin

% xxd response-1.bin
00000000: 0140 c840 a104 6461 7465 1d4d 6f6e 2c20  .@.@..date.Mon, 
00000010: 3237 204a 756c 2032 3030 3920 3132 3a32  27 Jul 2009 12:2
00000020: 383a 3533 2047 4d54 0673 6572 7665 7206  8:53 GMT.server.
00000030: 4170 6163 6865 0d6c 6173 742d 6d6f 6469  Apache.last-modi
00000040: 6669 6564 1d57 6564 2c20 3232 204a 756c  fied.Wed, 22 Jul
00000050: 2032 3030 3920 3139 3a31 353a 3536 2047   2009 19:15:56 G
00000060: 4d54 0465 7461 6714 2233 3461 6133 3837  MT.etag."34aa387
00000070: 2d64 2d31 3536 3865 6230 3022 0e63 6f6e  -d-1568eb00".con
00000080: 7465 6e74 2d6c 656e 6774 6802 3531 0c63  tent-length.51.c
00000090: 6f6e 7465 6e74 2d74 7970 650a 7465 7874  ontent-type.text
000000a0: 2f70 6c61 696e 3348 656c 6c6f 2057 6f72  /plain3Hello Wor
000000b0: 6c64 2120 4d79 2063 6f6e 7465 6e74 2069  ld! My content i
000000c0: 6e63 6c75 6465 7320 6120 7472 6169 6c69  ncludes a traili
000000d0: 6e67 2043 524c 462e 0d0a 00              ng CRLF....


  

Ici, le framing indicator vaut un, indiquant une réponse de longueur connue. Vous avez vu le C8 en troisième position ? C'est le code de retour 200.

Le format binaire de HTTP a été enregistré sous le nom message/bhttp.

Ah, et il existe au moins une autre mise en œuvre de ce RFC, en Go, dans ohttp-go.

Le titre fait référence à la Mésopotamie, étymologiquement « entre deux fleuves ». Ce livre (en anglais) présente divers aspects de la vie dans la Mésopotamie antique, à travers plusieurs personnes dont les noms et les activités ont franchi les siècles, grâce à une invention géniale : l'écriture.

L'auteure est historienne, spécialiste de la Mésopotamie et tient un compte Twitter très vivant, avec plein de descriptions d'inscriptions anciennes. Ici, le point de départ est le palais de la princesse Ennigaldi-Nanna, où se trouve toute une collection d'objets qui, même pour l'époque, étaient antiques. Un musée ? Une bibliothèque ? Un hobby ? En tout cas, Ennigaldi-Nanna n'est que l'une des personnes qui sont citées dans le livre. Car les gens de la Mésopotamie, ayant inventé l'écriture, ont beaucoup utilisé leur invention. Poèmes, romans, ouvrages historiques, liste de marchandises, documents comptables, correspondance diplomatique, ils et elles ont beaucoup écrit, et on sait lire leur écriture et on comprend les différentes langues utilisées. De quoi faire travailler les historien·nes et ce livre raconte certaines de leurs découvertes, en se focalisant sur la vie des gens (vous ne trouverez pas grand'chose sur les monuments).

On ne sait pas tout, bien sûr. Et certains historiens ont comblé les trous avec leur imagination. Comme le note l'auteure, « c'est parfois comme si on essayait de reconstruire l'histoire de la guerre d'Irak uniquement à partir des discours de George Bush ». Ce livre parle aussi de l'histoire de l'histoire, comment notre vision de la Mésopotamie et de ses habitant·es a changé au cours du temps. Et l'introduction explique, au moment où la science est attaquée de toute part, pourquoi l'histoire est importante.

Le livre est très lisible (pas besoin d'être historien·e professionnel·le, ni de parler sumérien ou akkadien) et très vivant. Outre la princesse (et grande prétresse, car on n'avait pas peur du cumul des mandats, à l'époque) Ennigaldi-Nanna, vous suivrez donc le scribe Nabû-shuma-iddin, le roi Shulgi, la tenancière de bistrot Ku-bau (vous verrez qu'elle a connu ensuite une belle ascension sociale), l'astronome Balasî, la malade Beltani, qui consultait les dieux sur sa santé, la poétesse Enheduanna, toutes et tous de vraies personnes qui ont existé, et dont le nom est écrit pour l'éternité sur des tablettes d'argile.

Ah, et puisque l'auteure raconte qu'elle a choisi cette voie professionnelle grâce à Irving Finkel, je vous incite fortement à voir ses géniales vidéos faites au British Museum, notamment dans la série Curator's Corner (ma préférée).

Pour commander le livre, l'auteure propose plusieurs liens.

On le sait, un des problèmes stratégiques de l'Internet est l'absence d'un protocole de messagerie instantanée standard et largement répandu. Autant le courrier électronique fonctionne relativement bien entre logiciels différents, autant la messagerie instantanée est un monde de jardins clos, incompatibles entre eux, et qui nécessite d'installer vingt applications différentes sur son ordiphone. L'interopérabilité reste un objectif lointain. Il n'y a pas de solution simple à ce problème mais le système MLS (Messaging Layer Security) vise à au moins fournir un mécanisme de sécurité pour les groupes, mécanisme qui peut ensuite être utilisé par un protocole complet, comme XMPP (RFC 6120). MLS est normalisé dans le RFC 9420 et cet autre RFC, le RFC 9750, décrit l'architecture générale.

Les services de sécurité que doit offrir MLS sont les classiques (confidentialité, notamment) et, bien sûr, doivent être assurés de bout en bout (l'opérateur du service ne doit pas pouvoir casser la sécurité et, par exemple, ne doit pas pouvoir lire les messages). Quand il n'y a que deux participants, c'est relativement facile mais MLS est prévu pour des groupes, allant de deux à potentiellement des centaines de milliers de participant·es.

Le protocole, on l'a vu, est spécifié dans le RFC 9420. Il repose sur l'envoi de messages de maintenance du groupe, comme le message Proposal, qui demande un changement dans la composition du groupe, ou Commit, qui va créer une nouvelle epoch, c'est-à-dire un nouvel état du groupe (la ressemblance avec le commit d'un VCS comme git est volontaire). Les clés effectivement utilisées pour le chiffrement sont liées à cet état, et changent avec lui.

Le protocole MLS repose sur deux services, qui doivent être fournis pour qu'il puisse fonctionner (voir aussi la section 7) :

• Un service d'authentification des utilisateurices, l'AS (Authentication Service, section 4 du RFC), qui permettre d'obtenir les clés publiques, avec la garantie qu'elles sont bien liées à l'identificateur utilisé par l'utilisateurice,
• Un service de livraison, le DS (Delivery Service, section 5), qui va se charger de porter les messages.

Il n'y a pas besoin de faire confiance au DS, tous les messages étant chiffrés. La seule possibilité d'action d'un DS malveillant serait de ne pas transmettre les messages. (Par contre, un AS malveillant pourrait casser toute la sécurité, en envoyant des clés publiques mensongères, permettant par exemple l'espionnage.)

MLS n'impose pas une forme particulière à l'AS et au DS. Par exemple, il pourrait utiliser une PKI (RFC 5280) traditionnelle comme AS. On l'a dit, MLS n'est pas une solution complète de messagerie instantanée, une telle solution nécessite aussi l'AS, le DS et plein d'autres choses. Parmi les systèmes existants, on peut noter que PGP repose sur les serveurs de clés et le Web of Trust comme AS et sur le courrier comme DS. Signal repose sur un système centralisé comme DS et sur une vérification des clés par les utilisateurices comme AS (voir aussi la section 8.4.3.1 de notre RFC, sur l'authentfication des utilisateurices).

Le RFC rappelle que MLS ne met pas de contrainte à ces messages de changement du groupe. Si on veut le faire (par exemple créer des groupes fermés au public), cela doit être fait dans le protocole complet, qui inclut MLS pour la partie « chiffrement au groupe ». Par contre, MLS impose que tous les membres du groupe connaissent tous les autres membres. Il n'y a pas de possibilité d'avoir des membres cachés (cela serait difficilement compatible avec le chiffrement de bout en bout). Et le DS peut, selon les cas, être capable de trouver ou de déduire la composition d'un groupe (voir section 8.4.3.2).

Mais alors, que fait MLS ? Il gère la composition des groupes et ses changements dans le temps, et le matériel cryptographique associé. Via le DS, tous les membres du groupe génèrent les clés secrètes nécessaires et les messages peuvent être chiffrés pour tout le monde. MLS ne comprend pas le format des messages, il chiffre des octets, sans avoir besoin de connaitre l'application au-dessus.

Ah, et un peu de sécurité (section 8 du RFC). Il est très recommandé de faire tourner MLS sur un transport chiffré, comme QUIC (RFC 9000) ou TCP+TLS (RFC 8446) car, même si certains messages sont chiffrés, des métadonnées ne le sont pas. MLS fonctionne sur l'hypothèse que tout ce qui n'est pas une extrêmité du réseau (une des machines qui communiquent) est un ennemi (RFC 3552).

Autre question de sécurité, les push tokens, qui ont fait parler d'eux lors de discussions sur la sécurité de certaines messageries instantanées. Ils sont utilisés pour la distribution de contenu, par exemple pour prévenir les utilisateurices qu'un nouveau message est arrivé. Sans système de push, les machines clients devraient périodiquement interroger les serveurs, ce dont leurs batteries se plaindraient certainement. Mais les push tokens ont l'inconvénient de pouvoir être liés à des informations permettant d'identifier un·e utilisateurice. Cela ne compromet pas le contenu des messages (qui est chiffré) mais donne accès à des métadonnées bien révélatrices. Et les États utilisent cette possibilité. Le problème est compliqué car il n'y a pas de solution de remplacement, à part l'attente active. C'est ainsi que Proton a noté : « That said, we will continue to use Apple and Google push notifications when the services are available on the device because unfortunately they are favored heavily by the operating system in terms of performance and battery life. »  Mais Tuta a fait un autre choix. Notre RFC suggère quelques pistes comme l'introduction de délais aléatoires.

La section 8 donne beaucoup d'autres conseils de sécurité et sa lecture est recommandée. Notez par exemple que le protocole MLS du RFC 9420 a fait l'objet de plusieurs analyses de sécurité (la liste figure dans la section 8.6).

Il existe un site Web du projet MLS mais il a très peu de contenu. Question mises en œuvre de MLS, une liste est disponible, citant, par exemple, la bibliothèque BouncyCastle ou bien OpenMLS (avec une documentation très complète).

Les objets connectés, vous le savez, sont une source d'ennuis et de risques de sécurité sans fin. Non seulement ils ne sont pas forcément utiles (faut-il vraiment connecter une brosse à dents au réseau ?) mais en outre, comme ils incluent un ordinateur complet, ils peuvent faire des choses auxquelles l'acheteur ne s'attend pas. Pour limiter un peu les risques, le RFC 8520 normalisait MUD (Manufacturer Usage Description), un mécanisme pour que le fournisseur du machin connecté documente sous un format analysable les accès au réseau dont l'objet avait besoin ce qui permet, par exemple, de configurer automatiquement un pare-feu, qui va s'assurer que la brosse à dents ne se connecte pas à Pornhub. Dans un fichier MUD, les services avec lesquels l'objet communique sont typiquement indiqués par un nom de domaine. Mais le DNS a quelques subtilités qui font que l'utilisation de ces noms nécessite quelques précautions, décrites dans ce nouveau RFC.

En fait, le RFC 8520 permet d'utiliser des noms ou bien des adresses IP, qui seront ensuite ajoutées dans les ACL du pare-feu. Évidemment, les noms de domaine, c'est mieux. Pas pour la raison qu'on trouve dans tous les articles des médias « les noms de domaine sont plus simples à retenir pour les humains » puisque les fichiers MUD ne sont pas prévus pour être traités par des humains. Mais parce qu'ils sont stables (contrairement aux adresses IP, qui changent quand on change d'hébergeur), qu'ils gèrent à la fois IPv4 et IPv6 et parce qu'ils permettent la répartition de charge, par exemple via un CDN.

Mais le pare-feu (sauf s'il espionne la résolution DNS préalable) ne voit pas les noms de domaine, il voit des paquets IP, avec des adresses IP source et destination. (Ainsi que les ports, si le paquet n'est pas chiffré.) Il va donc falloir résoudre les noms en adresses si on veut configurer le pare-feu à partir du fichier MUD, et c'est là que les ennuis commencent. Les exigences de sécurité sont contradictoires (section 9 du RFC) : on veut bloquer les accès au réseau mais « en même temps » les permettre. Cette permission est nécessaire pour que l'objet connecté puisse mettre à jour son logiciel, par exemple lorsqu'une faille de sécurité est découverte. Et c'est également nécessaire pour que le vendeur de l'objet puisse recevoir des quantités de données personnelles, qu'il revendra (ou se fera voler suite à un piratage).

Le plus simple (section 3 du RFC) pour traduire les noms de domaine du fichier MUD en adresses IP est évidemment que le contrôleur MUD, la machine qui lit les fichiers MUD et les traduit en instructions pour le pare-feu (RFC 8520, sections 1.3 et 1.6) fasse une résolution DNS normale et utilise le résultat. C'est simple et direct. Mais notre section 3 décrit aussi pourquoi ça risque de ne pas donner le résultat attendu. Par exemple, le résolveur DNS peut renvoyer les résultats (les différentes adresses IP) dans un ordre variable, voire aléatoire, comme décrit dans le RFC 1794. C'est souvent utilisé pour faire une forme grossière de répartition de charge. Si le résolveur renvoie toutes les adresses IP possibles, OK, le contrôleur MUD les autorise toutes dans le pare-feu. Mais s'il n'en renvoie qu'une partie, on est mal, celle(s) autorisée(s) ne sera pas forcément celle(s) utilisée(s) par l'objet connecté. Et la résolution peut dépendre du client (le RFC parle de « non-déterminisme » ; en fait, c'est parfaitement déterministe mais ça dépend du client, par exemple de sa géolocalisation). Si le serveur faisant autorité renvoie une seule adresse qui dépend de la localisation physique supposée de son client, et que le machin connecté et le contrôleur MUD n'utilisent pas le même résolveur DNS, des ennuis sont à prévoir : l'adresse autorisée sur le pare-feu ne sera pas celle réellement utilisée.

Si contrôleur et truc connecté utilisent le même résolveur, le risque d'incohérence est plus faible. Les réponses seront les mêmes pour les deux (contrôleur et chose connectée). Cela peut être le cas dans un environnement résidentiel où tout le monde passe par le CPE (la box) qui fait à la fois résolveur DNS, routeur NAT et pare-feu. Mais que faire si, par exemple, la brosse à dents ou l'aspirateur connecté utilisent un résolveur DNS public, quelque part dans le mythique nuage ?

La section 4 du RFC liste tout ce qu'il ne faudrait pas faire en matière d'utilisation du DNS par les objets connectés. Typiquement, l'objet connecté utilise HTTPS pour se connecter à son maitre (le vendeur de l'objet ; le gogo qui a acheté l'objet connecté croit en être propriétaire mais il dépend du vendeur, qui peut arrêter le service à tout moment). Pour le cas d'une mise à jour logicielle, le maitre informe alors si une mise à jour du logiciel est nécessaire, en indiquant l'URL où l'objet va pouvoir récupérer cette mise à jour. Évidemment, il est préférable pour la sécurité que cette mise à jour soit signée (RFC 9019). Notez que ce qui est bon pour la sécurité face au risque de piratage par un tiers n'est pas forcément bon pour le consommateur : la vérification de la signature va empêcher les utilisateurs de mettre leur propre logiciel par exemple parce que le vendeur ne fournit plus de mise à jour.

Questions bonnes pratiques, d'abord, il faut utiliser le DNS, donc un nom de domaine dans l'URL, pas des adresses IP littérales. Cette approche aurait certes l'avantage de fonctionner même quand la résolution DNS est défaillante, mais elle souffre des problèmes suivants :

• Il faut choisir entre une adresse IPv4 et IPv6, alors que le maitre ne sait pas forcément de quelle connectivité dispose l'objet. Si l'objet se connecte en IPv4 au maitre, celui-ci pourrait croire qu'une adresse IPv4 littérale est acceptable ce qui n'est pas vrai si l'objet est connecté via NAT64 (RFC 6146). Dans cet exemple, le DNS marcherait (RFC 6147) mais pas l'adresse littérale.
• Ensuite, l'adresse IP peut changer fréquemment, par exemple si le vendeur change d'hébergeur. C'est justement le principal avantage du DNS que de permettre une stabilité des identificateurs sur le long terme et non pas, comme on le lit souvent parce que « les noms sont plus lisibles et plus mémorisables que les adresses », argument qui ne s'applique pas aux objets connectés.
• Enfin, si la mise à jour est récupérée via HTTPS, ce qui est évidemment recommandé, le serveur doit obtenir un certificat et peu d'AC acceptent d'émettre des certificats pour des adresses IP (à l'heure de la publication de ce RFC, Let's Encrypt a annoncé qu'ils allaient le permettre mais cela ne semble pas encore fait).

Autre problème, des noms de domaine qui, en raison des systèmes utilisés sur le service HTTP, par exemple un CDN, changent souvent et de manière qui semble non déterministe. Modifier les fichiers MUD ne sera alors pas possible. Le RFC recommande, s'il faut absolument changer les noms souvent, de mettre un alias dans le fichier MUD, modifié à chaque fois que le nom change.

Toujours du côté des CDN, même s'ils ne sont pas les seuls à poser ce genre de problème, les noms trop génériques. Si tous les clients du service d'hébergement sont derrière le même nom de domaine, celui-ci sera difficile à modifier, et les effets d'une compromission pourront être plus étendus que souhaitable. Il vaut mieux des noms spécifiques à chaque client.

Les requêtes faites par le contrôleur MUD peuvent poser des problèmes de confidentialité (section 5 du RFC). Si le résolveur local n'est pas jugé digne de confiance, et que le contrôleur MUD utilise un résolveur distant, par exemple un résolveur public comme ceux de Cloudflare ou Quad9 (de préférence avec chiffrement, via DoH RFC 8484, DoT RFC 7858 ou DoQ RFC 9250), il faut s'assurer que l'objet va utiliser ce même résolveur (il n'y a pas aujourd'hui de mécanisme dans MUD pour faire cela automatiquement).

Les recommandations positives, maintenant (section 6). Le fichier MUD peut être obtenu de diverses façons (par exemple via un code QR comme documenté dans le RFC 9238), c'est son contenu qui compte. Les conseils de la section 6 sont en général du simple bon sens, qui correspondent aux bonnes pratiques habituelles d'utilisation des URL, mais qui ne sont pas toujours appliquées par les objets connectés. Notre RFC recommande :

• D'utiliser le DNS (et pas des adresses IP littérales comme le font trop de vendeurs),
• d'utiliser des noms contrôlés par le vendeur de l'objet (et pas par son hébergeur Web), éventuellement en utilisant des alias (RFC 9499, section 2),
• d'utiliser des CDN dont les serveurs faisant autorité retournent plusieurs réponses, quitte à les réordonnancer pour la répartition de charge, pour augmenter la probabilité que le contrôleur MUD et l'objet aient des adresses en commun,
• de ne pas utiliser des réponses adaptées au client DNS ; un mécanisme comme ECS (RFC 7871) permet de donner des réponses différentes selon l'adresse IP du client final (et pas celle du client que voit le serveur faisant autorité), ce qui va créer des problèmes si le contrôleur MUD et l'objet passent par des connexions Internet différentes,
• d'utiliser le résolveur local (celui indiqué via DHCP ou RA - RFC 8106), en s'appuyant sur les techniques décrites dans les RFC 9462 et RFC 9463 ; l'utilisation de résolveurs DNS publics est découragée, à mon avis pour de mauvaises raisons.

Notez que l'objet peut aussi utiliser des noms mais ne pas se servir du DNS pour les traduire en adresses IP. C'est le cas par exemple s'il utilise mDNS (RFC 6762 et RFC 8882) qui, en dépit de son nom, n'est pas du DNS, ce qui peut également poser des problèmes d'incohérence (l'objet n'obtenant pas la même adresse IP que le contrôleur MUD).

La section 8 revient sur les questions de vie privée (RFC 7626). Elle dit (ce qui est peut-être contestable) que les requêtes DNS d'un four à micro-ondes ne sont pas forcément un enjeu d'intimité mais que celles d'un sextoy le sont davantage. L'utilisation de DoT ou DoH va supprimer le risque d'une écoute par un tiers mais le résolveur, dans tous les cas, voit la requête et il faut donc choisir un résolveur de confiance, sauf à utiliser des techniques qui sont pour l'instant très rares, comme celle du RFC 9230. Ah, et le RFC discute aussi des risques posés par la divulgation de la version de logiciel actuellement utilisée par l'objet (qui va lui servir à savoir s'il faut une mise à jour) mais le RFC 9019 a déjà traité cela.