Stéphane Bortzmeyer

Homme blanc, hétéro, cis, > 50 ans, diplômé du supérieur, habitant à Paris et abonné à Charlie

  • RFC 7830 : The EDNS(0) Padding Option

    Ce nouveau #RFC fait partie de la série de ceux qui tentent d’améliorer la situation du #DNS pour tout ce qui concerne la protection de la #vie_privée. Parmi les efforts dans ce domaine, il y a une possibilité de chiffrement des communications DNS, dans le futur RFC DNS-sur-TLS. Elle utilise le protocole TLS. Ce dernier ne fait rien pour dissimuler la longueur des requêtes et réponses DNS. Or, de telles #métadonnées peuvent suffire à identifier les requêtes faites. Il est donc important de compléter le chiffrement avec un mécanisme de #remplissage (#padding). C’est ce que permet la nouvelle option #EDNS normalisée dans ce RFC.

    http://www.bortzmeyer.org/7830.html

    • Merci c’est très intéressant. Ça éveille chez moi quelques questions :

      # Quand les serveurs « standards » disponibles dans les distributions Linux proposeront ils le chiffrement, comme par exemple bind ?
      # Et il faut bien avoir un client qui supporte également ce chiffrement ?
      # Le chiffrement des requêtes « internes » faites par les applis (ex : getaddrinfo) sera-t-il activé ? Ça signifie intégrer ça au noyau ? Est-ce prévu par le projet Linux ? Sur la base de quelles RFC ?
      # Quels logiciels / solutions peut-on utiliser pour avoir aujourd’hui du chiffrement DNS en logiciel libre ?
      # Enfin... « As-t-on du code » est-il bien français ? « A-t-on » me semble plus indiqué cf. https://fr.wiktionary.org/wiki/t-on

    • @cocodaemon

      – Unbound a déjà DNS-sur-TLS. Pour BIND, je ne sais pas, il faut demander à ses auteurs. https://indico.dns-oarc.net/event/22/session/2/contribution/2/material/slides/1.pdf

      – oui, le chiffrement change le protocole, client et serveur doivent le gérer

      – getaddrinfo n’est pas dans le noyau. Pour une machine Linux typique, plutôt que de modifier la libc, il faudra sans doute, soit un résolveur local sur la machine, soit un relais (proxy) comme tproxy.

      – aujourd’hui, la seule solution publiée est DNScrypt mais DNS-sur-TLS aura l’avantage d’être normalisé

      – j’ai corrigé le barbarisme :-)

    • Une idée sur pourquoi cette option a été restreinte aux cas d’usage du chiffrement ? Cela aurait excellent pour l’anti-DDoS : on pad une question avec un nombre d’octets calculé par heuristique sur la taille anticipée de la réponse. Si la réponse excède la taille de la question de N%, elle est tronquée, sinon, elle est répondue. Cela permet de limiter le facteur d’amplification tout en restant en UDP, et cela sans maintenir d’état additionnel (notamment dans le cas du prefetch)

    • En fait, la terminologie dans le RFC est assez pauvre et manque clairement de rigueur, puisqu’elle confond chiffrement et authentification de la source de la donnée. Maintenant, concernant les attaques par amplification, je ne vois pas en quoi une requête claire plus grosse pourrait accroître l’amplification. La décision de mettre du padding est « hop-by-hop ». Au mieux, on diminue l’amplification puisqu’on pose une plus grosse question que nécessaire, pour générer une même réponse. La logique de raisonnement du RFC est complètement cassée. Je ne comprends pas comment un working group a pu laisser passer ça...

    • @X_cli Cette possibilité (« padder » les requêtes DNS) est discutée en ce moment sur la liste DNSOP. Les problèmes que cela pourrait poser : « this can affect some cases such as query packets not making it to the server due to size, lack of ability of the client to guess what the answer’s message size may be, and also EDNS UDP payload size behavior. In DNS over UDP and its poor-man’s-pMTU-discovery, it’s the client that
      drives the discovery of what works - the server has no idea of whether a
      query+answer roundtrip has succeeded in a reply successfully delivered
      to the client, whereas the client does. The client can use this to tweak
      the UDP payload size, but if the query itself may get dropped, it can’t
      tell if it was the query or the reply that disappeared - there is some
      faith that an unpadded question-only DNS message will go through
      somewhat reliably. »

      Et on me signale que la première mention de cette possibilité était apparue dans https://www.ietf.org/mail-archive/web/dnsop/current/msg12999.html

    • @stephane Merci Stéphane d’avoir porté cela à mon attention. Je comprends la position, mais je ne la partage pas.
      En effet, un serveur répondant TC à une question non paddée pourrait également répondre une option EDNS (en écho à l’option vide dans la question), avec la taille prévue pour la réponse. Le résolveur pourrait alors mémoriser (ou non) ces informations :
      1) Le serveur comprend cette option
      2) La taille de la réponse est prévue d’être XxX

      Ce n’est pas garanti de fonctionner puisque :
      – l’enregistrement peut changer de contenu entre les deux requêtes... mais ce doit être un cas relativement rare.

      – le problème peut être situé sur un boitier intermédiaire

      Il reste le risque que la requête, finalement pas beaucoup plus longue qu’une requête standard, soit droppée car l’option est inconnue et le comportement est anormal... On retombe alors sur un cas de classique de découverte de capacité du serveur, comme il est déjà fait pour EDNS dans BIND.