Mon blog

Dans ce livre, William Blanc, avec Justine Breton et Jonathan Fruoco, poursuit son exploration des mythes nés de héros de fiction. Car, si Robin des Bois n'a probablement jamais existé, le mythe, lui, est bien réel, et a été repris par d'innombrables créateurs, bien différents.

Ce livre commence par creuser les racines du mythe. Au Moyen Âge, il était suffisamment connu pour que les premières mentions écrites du héros, au détour d'autres ouvrages, ne soient pas expliquées : tous les lecteurs connaissaient la référence, grâce à la tradition orale. Puis Robin des Bois a eu droit à ses propres livres et pièces de théâtre, après le Moyen Âge, et a commencé une carrière médiatique que le cinéma, au XXe siècle, a puissamment relancé. Je rappelle que ce livre ne porte pas sur le personnage historique (qui est sans doute imaginaire) mais sur sa reprise par les créateurs. C'est l'histoire du mythe, pas l'histoire de Robin.

Comme avec tous les mythes, Robin des Bois a été utilisé par de nombreux courants artistiques et politiques. Si le roi Arthur, sujet d'un précédent livre du même auteur, est plutôt « de droite » (après tout, c'est un roi), Robin des Bois, proscrit caché dans la forêt, qui affronte les autorités, serait plutôt « de gauche ». Mais attention, c'est bien plus compliqué que cela et les auteurices du livre montrent que Robin des Bois a été présenté de nombreuses façons différentes, et parfois en allié du roi, ou, au XXe siècle, en libertarien partisan des esclavagistes. De même, Robin a souvent changé de classe sociale, parfois yeoman (paysan propriétaire), parfois noble. Bien des bandits et des rebelles ont été qualifiés de « Robin des Bois moderne » (y compris les plus contestables).

Le livre analyse aussi un certain nombre de points spécifiques : le rôle des femmes dans la légende, Robin des Bois en France, les questions que se posent les médias pour enfants (présenter un voleur comme personnage positif…), l'importance du déguisement dans la légende (et, de manière plus générale, de l'inversion), bref, un livre d'une grande richesse où vous découvrirez plein de choses.

Le protocole ACME, normalisé dans le RFC 8555, permet d'automatiser le processus de création et de renouvellement de certificats utilisables, par exemple, pour TLS. L'extension normalisée dans ce nouveau RFC permet d'obtenir et de renouveler des certificats pour un service utilisant le .onion de Tor. Si vous voulez passer à la télévision en disant « j'ai obtenu un certificat pour le Dark Web », ce RFC est la bonne lecture.

Ces services en .onion sont décrits dans la spécification de Tor. Le nom .onion a été enregistré comme « nom spécial » (RFC 6761) par le RFC 7686. Ces noms en .onion ne sont pas résolvables via le DNS et on ne peut donc pas utiliser les défis ACME (RFC 8555, section 8) classiques avec une AC habituelle.

La norme ACME, le RFC 8555, définit dans sa section 9.7.7 des types d'identificateurs. Pour les .onion, ce sera le type dns, même si Tor n'utilise pas le DNS. J'aurais préféré que ce type se nomme domainname, ça aurait été plus cohérent (voir l'annexe A du RFC, qui discute ce choix, qui prend place dans un cadre très embrouillé, avec beaucoup de gens qui confondent noms de domaine et DNS). L'identificateur est le nom dans .onion, éventuellement avec des sous-domaines. Par exemple, le JSON envoyé par ACME, pour la version en .onion de ce blog, serait :

{
  "type": "dns",
  "value": "sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion"
}
  

Reste à permettre au serveur ACME (l'AC) de le valider. Le forum AC/Navigateur permet les .onion (annexe B.2 de ses « Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates »). ACME utilise le concept de défi pour ces validations. Le client ACME demande un certificat pour un certain identificateur, le serveur lui renvoie un défi, une tâche à accomplir, du genre « prouve-moi que tu peux mettre ces données que je t'envoie dans un endroit accessible en HTTP via le nom pour lequel tu veux un certificat ». Il existe plusieurs défis utilisables avec les .onion :

• http-01 (section 8.3 du RFC 8555), notre RFC dit qu'il faut suivre les redirections HTTP, même si elles mènent à un serveur HTTP qui n'est pas en .onion ; c'est ce défi que j'ai utilisé pour mon blog.
• tls-alpn-01 (RFC 8737).
• onion-csr-01, qui, contrairement aux deux précédents, est spécifique aux .onion et normalisé dans ce RFC 9799. C'est aussi le seul des trois défis utilisables qui permettre des jokers dans l'identificateur (*.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726vq5kgwwn6aucdccrad.onion). Je le décris en détail plus loin. Cette méthode de validation figure désormais dans le registre des types de défis.
• dns-01 (section 8.4 du RFC 8555), par contre, ne peut pas être utilisé pour les .onion, ceux-ci ne se servant pas du DNS.

Le défi onion-csr-01 consiste à demander au client de générer une CSR (RFC 2986) signée avec la clé privée du nom en .onion (je rappelle qu'un nom en .onion est une clé publique, plus exactement est dérivé d'une clé publique). Pour cela, le serveur ACME envoie un numnique et sa clé publique Ed25519, qu'il utilise pour Tor. Le client doit répondre avec le CSR, signé avec sa clé privée, CSR contenant parmi ses attributs le numnique choisi par le serveur, et un autre choisi par le client. Le serveur vérifie alors ce CSR (le nom en .onion, et bien sûr la signature).

Notez qu'on peut imaginer une AC qui ne soit elle-même accessible que via un nom en .onion, ce qui serait cohérent (section 5 du RFC). Par contre, en sortie, une AC doit utiliser Tor pour se connecter aux .onion (je veux dire l'utiliser directement, pas en passant par une passerelle, cf. section 8.8) mais une AC ne doit pas utiliser Tor pour se connecter à des domaines non-onion (section 8.4) car il y a des nœuds de sortie méchants.

Et les enregistrements de type CAA, normalisés dans le RFC 8659, et qui augmentent la sécurité du système en indiquant à quelles AC le client ACME a recours ? On ne peut pas utiliser le CAA traditionnel puisqu'il dépend du DNS. La solution, décrite dans la section 6 du RFC, est de mettre cette information dans le descripteur de service Tor (celui que le serveur en .onion envoie aux serveurs d'annuaire Tor).

Passons à la pratique. Il existe une AC expérimentale (et qui ne prétend pas offrir les garanties de sécurité d'une « vraie »), par l'auteur du RFC, documentée sur le site Web du projet. Je m'en suis servi pour obtenir un certificat pour mon blog. Vous pouvez donc désormais vous connecter en HTTPS, à https://sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/ (votre navigateur va sans doute râler car il ne connait pas cette AC). Attention, l'AC a enregistré ce certificat via Certificate Transparency (RFC 9162) et est donc publiquement visible. Ne demandez pas de certificat à une AC qui utilise Certificate Transparency si ça vous dérange (section 8.9 du RFC).

Quelle est la marche à suivre pour obtenir un tel certificat ? D'abord, configurer Tor pour accepter le port de HTTPS :

  
  HiddenServiceDir /var/lib/tor/blogv2/
  HiddenServicePort 80 127.0.0.1:80
  HiddenServicePort 443 127.0.0.1:443

Ensuite, configurer son serveur HTTP, Apache dans mon cas :

  
# Pour le client ACME (qui écoutera sur le port 8080) :
ProxyPass /.well-known/acme-challenge http://localhost:8080/.well-known/acme-challenge
ProxyPassReverse /.well-known/acme-challenge http://localhost:8080/.well-known/acme-challenge
ProxyPreserveHost on
# Ne pas oublier d'activer mod_proxy *et* mod_proxy_http.

# HTTPS :
<VirtualHost _default_:443>
   ServerName sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion

   # Liens symboliques vers les certificats obtenus par ACME, dans mon
   # cas /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/…
   SSLCertificateFile	/etc/apache2/server.pem
   SSLCertificateKeyFile /etc/apache2/server.key

On lance ensuite le client ACME. J'ai utilisé certbot :

% sudo certbot certonly -v --server https://acme.api.acmeforonions.org/directory \
             --standalone --http-01-port 8080 --http-01-address 127.0.0.1 \
             -d sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
…
Performing the following challenges:
http-01 challenge for sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
Waiting for verification...
Cleaning up challenges
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/privkey.pem
This certificate expires on 2025-05-28.
…

(Et pensez à configurer le renouvellement automatique du certificat, normalement, certbot l'a fait tout seul, mais vérifiez.)

Un tcpdump montre le trafic échangé entre Apache (qui a reçu le défi de l'AC, via Tor) et certbot (qui avait envoyé la demande et stocké le défi du serveur ACME), sur ma machine :

    
127.0.0.1.60978 > 127.0.0.1.8080: Flags [P.] … HTTP, length: 376
	GET /.well-known/acme-challenge/G4JwaWsRDG42H_FAESGCQrY7ZYk3D3mY9Ob_j458z6M HTTP/1.1
	Host: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
	X-Forwarded-For: 127.0.0.1
	X-Forwarded-Host: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
	X-Forwarded-Server: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
	
127.0.0.1.8080 > 127.0.0.1.60978: Flags [P.] … HTTP, length: 92
	HTTP/1.0 200 OK
	Server: BaseHTTP/0.6 Python/3.11.2
	Date: Thu, 27 Feb 2025 17:04:53 GMT

  

Si vous voulez ajouter cette AC (mais rappelez-vous qu'elle est expérimentale et sans garanties de sécurité) au Tor Browser, vous devrez sans doute, dans about:config, configurer, avant d'importer l'AC :

security.nocertdb false
browser.privatebrowsing.autostart false
security.ssl.enable_ocsp_stapling false
  

Mais je répète mon avertissement : cela peut affecter votre vie privée. Ne le faites pas si vous ne comprenez pas en détail les conséquences.

J'ai utilisé le défi http-01, avec un certbot ordinaire. Le défi onion-01 nécessite un certbot modifié (du code est disponible).

Petite anecdote : l'auteur du RFC travaille pour l'AS 207960, dont l'objet RIPE annonce :

aut-num:        AS207960
as-name:        AS-TRANSRIGHTS
descr:          Trans Rights! Hell Yeah!

Et le site Web montre d'ailleurs le drapeau correspondant. Il est assez rare de voir des prises de position politiques dans la base des RIR.

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).