DANE nouveau draft : un protocole mort dans l'oeuf ?

Bonjour,
Un nouveau draft à propos de DANE est tombé hier : http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/

Je dois dire que je suis complètement ahuri par les modifications qui ont été apportées au draft. En résumé : DNSSEC obligatoire de bout-en-bout.

Obligatoire non seulement pour les type 2, mais également pour tous les types de ressources TLSA ! De plus, il est requis que le dernier kilomètre soit sécurisé...
Ainsi deux solutions s'offrent aux utilisateurs : utiliser un résolveur+validateur local, ou sécuriser leur communication entre le stub-resolver et le recurseur avec (je cite leurs exemples pour montrer le crétinisme) : TSIG (irréaliste du point de vue d'un déploiement à grande échelle, à moins que la validation se fasse dans les box, ce qui signifie faire confiance à son FAI (hum)... et son gouvernement...(hum bis...)), SIG(0) (dont il n'existe aucune implémentation, si j'ai bien compris, et donc aucune diffusion chez les clients), IPSEC (la bonne blague)...

Si l'obligation de sécurisation du dernier kilomètre avec DNSSEC peut être vue comme parfaitement logique pour le type 2 (en gros, trust anchor fournie par DNS), les types 0 et 1 ne font qu'ajouter des bretelles à la ceinture de X509... Ceinture qui ne serre pas grand chose, comme on a pu le voir ces derniers temps, mais qu'on utilise tout de même depuis 15 ans.
Alors oui, je suis d'accord qu'on est parfaitement sensible à une attaque MITM (man-in-the-middle) sur le dernier kilomètre s'il n'est pas sécurisé, mais il faut, je pense faire un compromis entre la sécurité (du point de vue de l'ingénieur) et celle qui est réellement apportée au client (0, s'il ne la met pas en place). Tout dépend contre qui on veut se défendre : le méchant qui pirate l'autorité de certification (ou l'autorité de certification malicieuse/incompétente), ou contre un attaquant actif visant M. Michu en particulier. 
Mon avis est que l'on doit répondre en "urgence" au premier problème (demande actuelle forte), et que le second peut être envisagé, mais à terme (en gros, un SHOULD au lieu d'un MUST dans la RFC).

Mais revenons à ce que propose la RFC. En gros, cela laisse trois alternatives pour M. Michu :
* Installer dnssec-trigger : hypothèse assez irréaliste de croire que M. Michu va installer sur sa machine un résolveur... il faudrait déjà qu'il sache à quoi ca sert, et ca ne l'intéresse pas (en revanche, les geeks aiment ce produit, merci :D)
* Avoir un validateur livré de base avec les OS... il faut donc que Microsoft et Apple (je ne parle pas des linuxiens qui peuvent "l'imposer" facilement) soient d'accord, et que les clients mettent le parc à jour... on est bon pour attendre 10 ans
* Avoir la validation faite dans les logiciels clients (les navigateurs pour l'usage principal). C'est ce que fait déjà l'extension Firefox "DNSSEC Validator"... On retombe alors sur le problème qu'il faut que Microsoft, Apple, Mozilla, et Opera soient d'accord pour implémenter un résolveur (qui marche) et que le parc soit à jour. Autant dire qu'on peut également ranger DANE dans le carton pour 10 ans.

Pour moi, cette mise à jour des pré-requis de DANE est purement synonyme de la mort dans l'oeuf du protocole.
Qu'en pensez vous ? Ai-je raté des choses ?

Cordialement,
Florian Maury