Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?
DANE est une des méthodes les moins intrusives (beaucoup moins que CT). Tout est déjà en place pour la supporter. Tous les serveurs et résolveurs DNS dignes de ce nom supportent déjà DNSSEC (et DANE n’a pas besoin d’être explicitement pris en charge, les enregistrements TLSA ne sont que des enregistrements DNS comme les autres). Aucun protocole n’a besoin d’être modifié. Tout ce qu’il manque est le support des navigateurs.
Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.
Ça c’est complètement faux. Côté serveurs, je le répète, tous les serveurs DNS dignes de ce nom gèrent DNSSEC. Côté client, ce n’est pas parce que les navigateurs regardent ailleurs que personne d’autre n’est intéressé. DNSSEC a bien d’autres intérêts au-delà du seul web.
Les serveurs de courrier électronique y ont un intérêt pour chiffrer les communications SMTP de serveur à serveur (en utilisant DANE pour authentifier le pair d’en face, et donc faire un peu mieux que du chiffrement à l’aveugle sans savoir à qui on parle). Les clients SSH y ont un intérêt pour authentifier les serveurs SSH (enregistrements SSHFP, seulement fiables si on est sûr que l’enregistrement n’est pas frauduleux).
Je ne dis pas que DNSSEC n’est pas monstrueux. Personne ne peut lire le RFC décrivant NSEC3 et ne pas penser que c’est une monstrueuse usine à gaz. Mais d’une part, ce n’est pas plus une usine à gaz que bien d’autres protocoles que l’on utilise sans même y penser (dont, au passage, X.509 et TLS, dont la complexité effare bien des experts en sécurité), et d’autre part, c’est complètement déployable et même déployé.
Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.
C’est du même niveau que les magouilles consistant à fabriquer des faux certificats à la volée. Que DNSSEC contrarie ce genre d’agissements est une feature, pas un bug. Les responsables « d’environnements pro » qui veulent contrôler le moindre traffic de leurs utilisateurs devront le faire de manière ouverte et assumée, pas dans le dos des utilisateurs.
L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.
Lesquels, et comment ? Par ailleurs, rien dans la description de CT ne laisse transparaître une telle « idée sur le long terme ».
[^] # Re: Et DANE simplement
Posté par gouttegd . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 4.
DANE est une des méthodes les moins intrusives (beaucoup moins que CT). Tout est déjà en place pour la supporter. Tous les serveurs et résolveurs DNS dignes de ce nom supportent déjà DNSSEC (et DANE n’a pas besoin d’être explicitement pris en charge, les enregistrements TLSA ne sont que des enregistrements DNS comme les autres). Aucun protocole n’a besoin d’être modifié. Tout ce qu’il manque est le support des navigateurs.
Ça c’est complètement faux. Côté serveurs, je le répète, tous les serveurs DNS dignes de ce nom gèrent DNSSEC. Côté client, ce n’est pas parce que les navigateurs regardent ailleurs que personne d’autre n’est intéressé. DNSSEC a bien d’autres intérêts au-delà du seul web.
Les serveurs de courrier électronique y ont un intérêt pour chiffrer les communications SMTP de serveur à serveur (en utilisant DANE pour authentifier le pair d’en face, et donc faire un peu mieux que du chiffrement à l’aveugle sans savoir à qui on parle). Les clients SSH y ont un intérêt pour authentifier les serveurs SSH (enregistrements SSHFP, seulement fiables si on est sûr que l’enregistrement n’est pas frauduleux).
Je ne dis pas que DNSSEC n’est pas monstrueux. Personne ne peut lire le RFC décrivant NSEC3 et ne pas penser que c’est une monstrueuse usine à gaz. Mais d’une part, ce n’est pas plus une usine à gaz que bien d’autres protocoles que l’on utilise sans même y penser (dont, au passage, X.509 et TLS, dont la complexité effare bien des experts en sécurité), et d’autre part, c’est complètement déployable et même déployé.
C’est du même niveau que les magouilles consistant à fabriquer des faux certificats à la volée. Que DNSSEC contrarie ce genre d’agissements est une feature, pas un bug. Les responsables « d’environnements pro » qui veulent contrôler le moindre traffic de leurs utilisateurs devront le faire de manière ouverte et assumée, pas dans le dos des utilisateurs.
Lesquels, et comment ? Par ailleurs, rien dans la description de CT ne laisse transparaître une telle « idée sur le long terme ».