\include{parameters}
\usetheme{AFNIC}
\usepackage[french]{babel}
\usepackage[latin1]{inputenc}
\usepackage{bortzmeyer-utils}
\usepackage{underscore}

\title{Des clés dans le DNS, pour remplacer X.509 ?}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{JRES, 23 novembre 2011}

%\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex} 
% \setlength{\parskip}{15pt} 
\setlength{\parskip}{15pt plus 10pt minus 10pt} 

\begin{document}

\maketitle

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
\frametitle{X.509, c'est quoi ?}
\begin{itemize}
\item<1-> X.509 est une norme de certificats (certificat = clé +
méta-données + signature) numériques.
\item<2-> Son modèle de sécurité est qu'une AC (Autorité de
Certification)  signe le certificat
après vérification. Les utilisateurs font ensuite confiance aux AC
(compétence, honnêteté, sécurité). Le modèle est donc multi-racines.
\item<3-> Qui décide de qui est une AC ? Mozilla ? Microsoft ? L'ANSSI
(cf. RGS) ? Le CNRS ? L'utilisateur ?
\end{itemize}

\end{frame}

\begin{frame}
\frametitle{Utilisation de X.509 dans l'Internet}
\begin{itemize}
\item<1-> L'utilisation la plus courante dans l'Internet est pour TLS,
surtout HTTPS.
\item<2-> Le serveur présente un certificat, le client peut vérifier
que ce certificat a été signé par une AC de son magasin. Et cela
permet d'afficher un joli cadenas.
\item<3-> Cela protège contre le terrible Homme au Milieu.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les problèmes et limites de X.509}
\begin{block}
{Le principal problème de X.509}
{Il est multi-racines, avec un \computer{OR} entre les racines. Un
certificat signé par \emph{n'importe quelle AC du magasin} convient. Il ne sert
donc à rien de choisir soigneusement son AC.}
\end{block}
\end{frame}

\begin{frame}
\frametitle{2011, année terrible pour X.509}
\begin{enumerate}
\item <1-> Mars, Comodo est détourné via un revendeur (le mot de passe
était dans la DLL) et émet des vrais-faux certificats pour \computer{gmail.com}.
\item <2-> Août, Opération « Tulipe Noire », DigiNotar est piraté
(même plus de traçabilité) et émet plein de vrais-faux certificats. La
société se met en faillite, pour éviter d'assumer ses responsabilités.
\item <3-> Octobre, l'EFF révèle, en analysant les révocations, que
quatre autres AC avaient été compromises sans que cela soit révélé publiquement.
\end{enumerate}
\end{frame}

\begin{frame}
\frametitle{Autres modèles de sécurité}
\begin{itemize}
\item <1-> Le modèle TOFU (SSH ou bien extensions au navigateur HTTPS,
comme par exemple CERT Patrol). On fait confiance au certificat la
première fois et on ne s'inquiète que s'il change ensuite. 
Mais il est difficile de savoir si un changement est légitime ou pas
(cas de Facebook en octobre).
\item <2-> Les modèles à réseau de pairs, qu'on interroge pour savoir
ce qu'ils pensent (Perspectives ou Convergence). Intéressant car
purement pair à pair. Mais peu de réalisations concrètes encore.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Mettre les clés dans le DNS}
Troisième approche : réutiliser l'infrastructure et les réseaux de
confiance existants, en mettant les clés/certificats dans le DNS.
\begin{itemize}
\item <1-> C'est le projet DANE (\foreign{DNS-based Authentication of
Named Entities}) de l'IETF. Cahier des charges dans le
RFC 6394.
\item <2-> DANE a trois modes d'opération, selon qu'on veut plus ou
moins couper les ponts avec X.509.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les trois modes de DANE}
\begin{itemize}
\item <1-> Type 0 : on ajoute dans le DNS le certificat de son AC,
évitant ainsi les attaques de type DigiNotar. On continue à valider
avec X.509.
\item <2-> Type 1 : très proche du type 0, on ajoute dans le DNS son
certificat, ce qui protège même contre sa propre AC.
\item <3-> Type 2 : on dit adieu à X.509, on publie son certificat
dans le DNS et aucune validation X.509 n'est faite.
\end{itemize}
\end{frame}

\begin{frame}[fragile]
\frametitle{Exemple d'enregistrement DANE - type 1}
\emph{Avertissement} : le protocole n'est pas fini, la syntaxe peut changer.

Cet enregistrement dit « voici ma clé publique, fais les deux vérifications,
X.509 et cette clé » (type 1, le premier champ après ``DANE'')
\begin{info}
   _443._tcp.www.example.com. IN DANE (
      1 1 2 92003ba34942dc74152e2f2c408d29ec
            a5a520e7f2e06bb944f4dca346baf63c
            1b177615d466f6c4b71c216a50292bd5
            8c9ebdd2f74e38fe51ffd48c43326cbc )
\end{info}
\only<2->{(Deuxième champ après ``DANE'' : 1 pour ``clé'', troisième
      champ, 2 pour ``condensat SHA-512'')}
\end{frame}

\begin{frame}[fragile]
\frametitle{Exemple d'enregistrement DANE - type 2}
Cet enregistrement dit « voici mon certificat, oublie X.509, cette
affirmation suffit »
\begin{info}
   _443._tcp.www.example.com. IN DANE (
      2 0 0 30820307308201efa003020102020... )
\end{info}
\only<2->{(Deuxième champ après ``DANE'' : 0 pour ``certificat complet'', troisième
      champ, 0 pour ``valeur effective, pas condensat'')}
\end{frame}

\begin{frame}
\frametitle{L'importance de DNSSEC}
\begin{itemize}
\item <1-> Évidemment, tout ceci suppose que le client récupère le bon
enregistrement DANE, malgré l'Homme au Milieu
\item <2-> Le DNS est trop vulnérable pour cela (faille Kaminsky)
\item <3-> DNSSEC est donc indispensable (quasi-indispensable ?) à
DANE 
\item <4-> C'est pourquoi, malgré les vulnérabilités connues de
X.509, l'idée de sérieusement le remplacer par des clés dans le DNS
est récente. (Elle date du déploiement effectif de DNSSEC, en 2010.)
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{DNS+DNSSEC est-il un progrès ?}
Pour ne pas remplacer une technique percée par une autre
analysons la sécurité de DNS + DNSSEC.
\begin{itemize}
\item<1-4>DNSSEC n'est pas encore déployé partout : la racine et tous
les gros TLD, mais pas beaucoup de domaines en dessous (20~\% en
Tchéquie, beaucoup moins en France).
\item<2-4>Peu de résolveurs valident (coucou aux gens de Lothaire,
qui le font).
\item<3->DNSSEC ne protège pas contre le contenu qui était incorrect
au départ. Si le registre est piraté (cas de
l'affaire \computer{www.google.bd}), DNSSEC ne pourra rien faire.
\item<4->Les acteurs des noms de domaine sont-ils meilleurs que les
AC X.509 ? Pas forcément.
\item<5->Mais, au moins, leur pouvoir est borné. Le registre
de \path{.BD} peut être incompétent, cela n'affectera pas \computer{www.google.fr}.
\end{itemize}
\end{frame}

\end{document}