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

Le 21 déc. 2011 à 09:14, Stephane Bortzmeyer a écrit :

> On Tue, Dec 20, 2011 at 11:37:18AM +0100,
> Florian Maury <[email protected]> wrote 
> a message of 22 lines which said:
> 
>> 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
> 
> Tout à fait. Techniquement, il n'y a pas d'autre solution
> raisonnable. Le nouveau draft dit (la première phrase s'applique à
> dnssec-trigger) :
> 
>   Clients that validate the DNSSEC signatures themselves SHOULD use
>   standard DNSSEC validation procedures.  Clients that do not validate
>   the DNSSEC signatures themselves MUST use a secure transport (e.g.,
>   TSIG [RFC2845], SIG(0) [RFC2931], or IPsec [RFC6071]) between
>   themselves and the entity performing the signature validation.
> 
> C'est dommage qu'il n'y ait pas trois points de suspension pour
> indiquer explicitement d'autres possibilités mais « e.g. » indique que
> ce ne sont que des exemples, on peut utiliser DNS-sur-DTLS ou bien
> OpenVPN.


Tout à fait. J'ai conclu la même chose à propos du "e.g.".

J'ai dit au revoir à 5h de ma vie hier pour lire l'ensemble de la discussion à propos de l'obligation ou non d'utiliser DNSSEC sur la mailing list de DANE à l'IETF, et s'il m'apparait désormais clairement qu'il n'est pas raisonnable de ne pas utiliser DNSSEC (pour les types 0/1), je n'ai vu nulle trace de discussion à propos de la sécurisation du dernier kilomètre.
Et pour cause, il semblerait que ce point (issue #8 dans le tracker, et référencé comme tel dans la mailing list) ait été discuté à l'oral lors d'un meeting ayant réuni quelques uns des membres du groupe de travail et ajouté arbitrairement dans le draft, pour faire avancer les choses. Il doit encore être soumis à l'approbation de la majorité.

Encore une fois, du point de vue de l'ingénieur, il est parfaitement logique de vouloir sécuriser le dernier kilomètre, sans quoi on a un trou béant dans la sécurité du système, et un point d'entrée évident pour une attaque.
(A noter qu'il existe une autre méthode d'attaque en déni de service, qui a été abordée sur la liste (Martin Rex), qui consiste pour un attaquant en coupure à empoisonner le client avec des réponses DNSSEC invalides (bogus), ce qui dans l'état du draft provoque un échec instantané de la transaction TLS).
Du point de vue de l'utilisateur, et "marketing" (mon dieu, si je me mets à réfléchir comme un marketeux... que qqn m'abatte), en revanche, il me semble toujours complètement illusoire de voir une adoption rapide de DANE, si cette obligation de sécurisation est maintenue.
Contrairement à votre réponse d'hier, je ne vois pas les administrateurs de poste de travail installer dnssec-trigger sur les machines. Ils vont associer l'idée d'un récurseur local à la machine, à tous les problèmes d'administration qu'ils ont avec leur serveur DNS "public" (a.k.a. authoritaire ; alors qu'on sait très bien que ca n'a rien à voir) et vont renoncer.

La solution de déploiement la plus "logique" (pour un déploiement rapide) me semble être l'intégration du validateur dans le client TLS comme le fait déjà l'extension "dnssec validator" de firefox. Ce n'est autant un frein que je le pensais hier, car de toute façon les clients TLS doivent être modifiés pour être compatibles avec DANE. On est cependant presque certains d'avoir des implémentations buguées puisque multiples, ce qui n'est clairement pas un atout. 
Pour moi, le draft doit être modifié ainsi :


    Clients that validate the DNSSEC signatures themselves SHOULD use
    standard DNSSEC validation procedures.  Clients that do not validate
!   the DNSSEC signatures themselves SHOULD use a secure transport (e.g.,
    TSIG [RFC2845], SIG(0) [RFC2931], or IPsec [RFC6071]) between
    themselves and the entity performing the signature validation.


Je suis d'accord que de toute façon, dans les faits, si l'obligation est maintenue, la plupart des implémenteurs l'ignoreront...

Florian Maury