Du côté de chez Google ? De mémoire les deux principales raisons officiellement avancées sont :
DNSSEC (dont DANE dépend) se repose trop sur RSA 1024, alors que tout le monde veut se débarasser de RSA 1024 ;
DANE augmente les risques de fishing, puisque n’importe qui peut obtenir un nom de domaine pour, par exemple, paypa1.com, et publier dans cette zone un certificat qui serait accepté par le navigateur (si les navigateurs supportaient DANE).
Le premier argument était déjà de mauvaise foi à l’époque : les clefs DNSSEC de 1024 étaient déjà en train d’être progressivement remplacées par des clefs de 2048 bits, et DNSSEC permet aussi l’utilisation de clefs ECDSA pour ceux qui trouvent que des clefs RSA de 2048 bits sont trop volumineuses pour le DNS.
Pour ce qui est du deuxième... mort de rire, comme si les autorités de certification faisaient quoi que ce soit contre le phishing... (Il est vrai que certaines prennent le temps de vérifier, avant de délivrer un certificat, que le nom demandé n’est pas « trop proche » d’un nom bien connu comme paypal et assimilés. Mais : 1 toutes ne le font pas — elles n’ont aucune obligation de le faire — et la magie du système des CA est que la fiabilité du système est celle de la moins fiable des CA ; 2 cette protection anti-fishing, quand elle est mise en œuvre que pour protéger les « gros » sites bien connus, les autres peuvent aller se faire voir.)
La véritable raison est que pour Google, toute technique qui permettrait de se passer des CA (comme DANE ou HPKP quand on les utilise pour épingler un certificat auto-signé ou signé par une autorité « non-reconnue ») est à banir. Pour des raisons qui m’échappent, Google considère que les CA sont une pierre angulaire d’Internet et il est hors de question de s’en passer. Certificate Transparency sert précisément à rendre les CA encore plus indispensables qu’elles ne le sont déjà. À cela s’ajoute une certaine défiance envers tout ce qui passe par le DNS.
Pour ceux qui trouveraient que j’exagère sur les intentions de Google : regardez par exemple ce qu’ils ont fait avec leur proposition SMTP-STS (SMTP Strict Transport Security, en gros la transposition de HTTP STS pour les serveurs mails). La première version du brouillon était prévue pour interagir sans heurts avec DANE : il y était dit que SMTP-STS pouvait être utilisé aussi bien seul que conjointement avec DANE, et qu’il y avait des avantages spécifiques à utiliser les deux ; l’utilisation d’un certification auto-signé (ou signé par une CA « non-reconnue ») était aussi explicitement autorisée si ledit certificat était publié dans le DNS. Un mois plus tard, le brouillon suivant fait machine arrière toute : la cohabitation entre DANE et SMTP-STS (renommé MTA-STS) n’est plus envisagée, DANE est désormais décrit comme un mécanisme concurrent ; la politique STS, qui pouvait auparavant être publié dans le DNS, doit désormais être récupéré via HTTPS ; et la possibilité d’utiliser un certificat auto-signé a complètement disparu, désormais le certificat doit être signé par une CA « reconnue ». Voyez-y ce que ce vous voulez, mais pour moi entre le premier et le deuxième brouillon quelqu’un chez Google (la plupart des auteurs des deux brouillons sont chez Google) s’est rappelé que tout ce qui pouvait permettre de réduire l’emprise des CA était à proscrire.
Au-delà de chez Google, pourquoi DANE n’est pas davantage répandu de manière générale ? Probablement un problème d’œuf et de poule, je suppose : les navigateurs ne l’implémentent pas (en tout cas pas nativement), donc côté serveur on ne le déploie pas (note : côté serveur, il n’y a plus rien à implémenter, tout ce dont on a besoin est d’un serveur DNS supportant DNSSEC, ce qui est le cas de n’importe quel serveur DNS digne de ce nom), donc on ne l’implémente pas côté client, donc on ne le déploie pas côté serveur, et ainsi de suite... Sans un « gros » pour pousser les choses (comme Google qui pousse Certificate Transparency), ça ne va pas bien loin...
(Je pense personnellement qu’on franchirait déjà un grand pas si les systèmes d’exploitation pouvait être fourni avec un résolveur DNS validant par défaut, ce qui à ma connaissance n’est aujourd’hui le cas d’aucun OS. Ce n’est pas normal qu’il faille être un « geek » pour pouvoir bénéficier d’une résolution DNSSEC sur sa machine...)
[^] # Re: Google, roi du pétrole
Posté par gouttegd . En réponse au lien HPKP est (bientôt) mort. Évalué à 7.
Du côté de chez Google ? De mémoire les deux principales raisons officiellement avancées sont :
Le premier argument était déjà de mauvaise foi à l’époque : les clefs DNSSEC de 1024 étaient déjà en train d’être progressivement remplacées par des clefs de 2048 bits, et DNSSEC permet aussi l’utilisation de clefs ECDSA pour ceux qui trouvent que des clefs RSA de 2048 bits sont trop volumineuses pour le DNS.
Pour ce qui est du deuxième... mort de rire, comme si les autorités de certification faisaient quoi que ce soit contre le phishing... (Il est vrai que certaines prennent le temps de vérifier, avant de délivrer un certificat, que le nom demandé n’est pas « trop proche » d’un nom bien connu comme paypal et assimilés. Mais : 1 toutes ne le font pas — elles n’ont aucune obligation de le faire — et la magie du système des CA est que la fiabilité du système est celle de la moins fiable des CA ; 2 cette protection anti-fishing, quand elle est mise en œuvre que pour protéger les « gros » sites bien connus, les autres peuvent aller se faire voir.)
La véritable raison est que pour Google, toute technique qui permettrait de se passer des CA (comme DANE ou HPKP quand on les utilise pour épingler un certificat auto-signé ou signé par une autorité « non-reconnue ») est à banir. Pour des raisons qui m’échappent, Google considère que les CA sont une pierre angulaire d’Internet et il est hors de question de s’en passer. Certificate Transparency sert précisément à rendre les CA encore plus indispensables qu’elles ne le sont déjà. À cela s’ajoute une certaine défiance envers tout ce qui passe par le DNS.
Pour ceux qui trouveraient que j’exagère sur les intentions de Google : regardez par exemple ce qu’ils ont fait avec leur proposition SMTP-STS (SMTP Strict Transport Security, en gros la transposition de HTTP STS pour les serveurs mails). La première version du brouillon était prévue pour interagir sans heurts avec DANE : il y était dit que SMTP-STS pouvait être utilisé aussi bien seul que conjointement avec DANE, et qu’il y avait des avantages spécifiques à utiliser les deux ; l’utilisation d’un certification auto-signé (ou signé par une CA « non-reconnue ») était aussi explicitement autorisée si ledit certificat était publié dans le DNS. Un mois plus tard, le brouillon suivant fait machine arrière toute : la cohabitation entre DANE et SMTP-STS (renommé MTA-STS) n’est plus envisagée, DANE est désormais décrit comme un mécanisme concurrent ; la politique STS, qui pouvait auparavant être publié dans le DNS, doit désormais être récupéré via HTTPS ; et la possibilité d’utiliser un certificat auto-signé a complètement disparu, désormais le certificat doit être signé par une CA « reconnue ». Voyez-y ce que ce vous voulez, mais pour moi entre le premier et le deuxième brouillon quelqu’un chez Google (la plupart des auteurs des deux brouillons sont chez Google) s’est rappelé que tout ce qui pouvait permettre de réduire l’emprise des CA était à proscrire.
Au-delà de chez Google, pourquoi DANE n’est pas davantage répandu de manière générale ? Probablement un problème d’œuf et de poule, je suppose : les navigateurs ne l’implémentent pas (en tout cas pas nativement), donc côté serveur on ne le déploie pas (note : côté serveur, il n’y a plus rien à implémenter, tout ce dont on a besoin est d’un serveur DNS supportant DNSSEC, ce qui est le cas de n’importe quel serveur DNS digne de ce nom), donc on ne l’implémente pas côté client, donc on ne le déploie pas côté serveur, et ainsi de suite... Sans un « gros » pour pousser les choses (comme Google qui pousse Certificate Transparency), ça ne va pas bien loin...
(Je pense personnellement qu’on franchirait déjà un grand pas si les systèmes d’exploitation pouvait être fourni avec un résolveur DNS validant par défaut, ce qui à ma connaissance n’est aujourd’hui le cas d’aucun OS. Ce n’est pas normal qu’il faille être un « geek » pour pouvoir bénéficier d’une résolution DNSSEC sur sa machine...)