6012 links
  • GuiGui's Show

  • Home
  • Login
  • RSS Feed
  • Tag cloud
  • Picture wall
  • Daily
Links per page: 20 50 100
page 1 / 1
  • Blog Stéphane Bortzmeyer: IETF 119 hackathon: compact denial of existence for DNSSEC

    + https://blog.cloudflare.com/black-lies/
    + https://www.bortzmeyer.org/9824.html

    Intéressante différence entre les « white lies » et les « black lies » DNSSEC. Les white lies sont normalisés, les black lies, invention de Cloudflare, sont en cours de normalisation.

    Avec DNSSEC, pour signifier qu'un nom DNS n'existe pas, un serveur DNS qui fait autorité répond, dans des enregistrements de type NSEC ou NSEC3, une plage signée de noms situés lexicalement avant et après le nom demandé (+ NXDOMAIN). Ces plages, chaînées les unes aux autres, sont générées en amont (enregistrements de type NSEC ou NSEC3). Détails.

    Deux problèmes : 1) ça empêche la mise à jour dynamique d'une zone DNS (ajout/retrait de noms) puisqu'on peut ignorer les noms qui viennent avant ou après ; 2) ça permet l'énumération de tous les noms d'une zone DNS (il suffit de suivre la chaîne de NSEC ou de NSEC3, et NSEC3, qui est un condensé cryptographique, ne protège que les zones contenant des noms imprédictibles). Détails.

    White lies : le serveur DNS qui fait autorité répond, en sus de NXDOMAIN, dans des enregistrements NSEC, des noms lexicalement très proches de celui demandé (un avant, un après, comme d'hab), mais qui n'existent pas. Ainsi, ces enregistrements NSEC couvrent une plus petite plage, donc ils ne divulguent pas le prochain enregistrement DNS réel dans l'ordre lexical. Pas besoin de chercher en base les noms les plus proches qui existent réellement. Mais il faut encore beaucoup de calculs cryptographiques (à l'échelle d'un très gros fournisseur, comme Cloudflare). On a donc : SOA, RRSIG SOA, NSEC nom précédent et nom suivant, RRSIG de ce NSEC, NSEC joker, RRSIG de ce NSEC.

    Black lies (aka Compact Denial of Existence) : le serveur qui fait autorité répond uniquement NOERROR avec, de type NSEC, le nom demandé et ce nom préfixé par « \000. » (permettant de prouver qu'il n'y a pas de joker). En gros, la réponse se lit comme : ce nom existe, mais uniquement pour les types NSEC, RRSIG et TYPE128. Moins de calculs cryptos, réponses plus courtes, et aucune recherche en base des noms qui existent vraiment. On a donc : SOA, RRSIG SOA, NSEC, RRSIG NSEC. (TYPE128, futur NXNAME : permet de dire aux serveurs DNS récursifs que le nom demandé n'existe vraiment pas, afin qu'ils puissent mieux informer leurs clients. Ce type n'est pas encore normalisé.)

    Même principe pour un nom qui existe mais pas dans le type demandé : au lieu de répondre les types qui existent réellement, ce qui implique une recherche en base, on peut répondre que tous les types existent sauf celui demandé (même si c'est faux).

    Dans les deux cas, black ou white lies, le serveur qui fait autorité doit avoir accès aux clés privées, puisque signature à la volée (= online signing).

    30/08/2025 22:34:14 - permalink -
    - https://www.bortzmeyer.org/hackathon-ietf-119.html
Links per page: 20 50 100
page 1 / 1
Mentions légales identiques à celles de mon blog | CC BY-SA 3.0

Shaarli - The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community