Dossier Thematique12 VF1

Dossier thmatique n12
Association Franaise pour le Nommage Internet en Coopration | www.afnic.fr | contact@afnic.fr | Twitter : @AFNIC | Facebook : afnic.fr
Aujourdhui, prs de 2,5 milliards de personnes utilisent Internet pour communiquer et fournir/obtenir des infor-
mations. Lorsque la communication concerne des informations sensibles telles que des coordonnes bancaires,
des numros de cartes de crdit, des dossiers mdicaux, etc., la mthode de communication doit tre scurise.
Lchange dinformations sur lInternet nest pas scuris par dfaut, ce qui induit un risque variable dattaques
malveillantes telles que la corruption des donnes, lusurpation didentit, etc.
Avec lvolution de lInternet, de nouveaux mcanismes de scurit sont devenus ncessaires, que ce soit en rai-
son de lmergence de nouveaux types dattaques ou de lidentifcation de nouvelles failles de scurit. Des solu-
tions ont t proposes et dployes progressivement. Ces solutions comprennent entre autres IPSec (Internet
Protocol Security) pour scuriser la couche rseau (galement appele couche IP), TLS (Transport Layer Security)
pour scuriser la communication entre deux applications Internet, telles quun serveur Web et un navigateur Web,
DNSSEC (Domain Name System Security Extensions) pour scuriser le processus de rsolution DNS, etc.
nonc du problme
Une solution permettant de
dployer un dispositif de
scurit de bout-en-bout :
DANE
En conclusion : DANE ou
la pice jusqu prsent
manquante au dispositif de
scurisation de bout-en-bout
de lInternet ?
1
2
3
Scuriser les communications
sur Internet de bout-en-bout
avec le protocole DANE
Ces dernires annes, des attaques de haut niveau, ciblant linfras-
tructure cls publiques X.509 (PKIX) utilise pour scuriser les
communications Internet, ont suscit un besoin urgent dune tech-
nologie permettant de corriger la faille de scurit prsente dans
lcosystme PKIX. Cest dans ce contexte que la communaut
IETF (Internet Engineering Task Force) a propos le protocole/m-
canisme DANE (DNS - based Authentication of Named Entities) qui
sappuie sur le DNS pour authentifer des entits applicatives.
Ce document explique le protocole DANE et comment DANE pour-
rait apporter la confance ncessaire dans linfrastructure du dernier
kilomtre en sappuyant sur DNSSEC. Ce document est destin un
public ayant une certaine connaissance des protocoles dInternet en
gnral et du systme de noms de domaine (DNS) en particulier. Ce
document prsente le protocole DANE et explique comment DANE
corrige la faille de scurit existant dans lInternet tout en assurant
une communication de bout-en-bout. Ce dossier thmatique nest
pas suffsant pour permettre un administrateur de domaine dim-
plmenter DANE.
2
La fgure suivante illustre une communication Internet type, une navigation sur le Web :
Cette fgure met en vidence deux oprations :
1. tant donn que le cerveau humain nest pas capable de mmoriser un grand nombre de numros (adresses
IP) la fois, mais quil est bien quip pour se souvenir de noms, des noms de domaine sont normalement uti-
liss lors de linterrogation dun service sur Internet. Mais, tant donn que les applications Internet ont besoin
dadresses IP pour communiquer entre elles, le DNS est utilis comme Annuaire de noms, gnralement
pour obtenir ladresse IP associe un serveur donn identif par son nom.
2. Ladresse IP obtenue est ensuite utilise par lapplication (c.--d. le navigateur Web illustr en Figure 1) pour
engager une communication Internet avec le serveur Web distant.
Les deux oprations mentionnes prcdemment ne sont pas intrinsquement scurises. Par dfaut, lorsque
des informations sont transmises au cours de la rsolution DNS ou lors dun accs au serveur pour changer
des donnes, aucune procdure dauthentifcation ou de chiffrement nest applique. Il existe par consquent au
cours de ces oprations de nombreuses possibilits permettant un attaquant de fournir de fausses informations,
comme une adresse IP frauduleuse lors de la rsolution DNS, et de rediriger ainsi lutilisateur vers un serveur
frauduleux.
En ce qui concerne la premire opration (rsolution DNS), la scurisation de la communication peut tre assure
par DNSSEC. Nous dcrirons plus loin dans ce dossier comment DNSSEC amliore la scurit. Pour la seconde
opration (connexion entre le navigateur et le serveur Web), le protocole TLS vient la rescousse en permettant
au client et au serveur de sauthentifer mutuellement et de ngocier un algorithme de chiffrement et des cls
cryptographiques avant que les donnes ne soient changes. TLS garantit que les donnes ne peuvent tre lues
ou altres par un tiers lors du transfert, puisquelles sont chiffres.
Fig. 1 :
Communication
Internet
typique avec
possibilits
dattaque au
cours des deux
oprations
1
2
192.134.4.20
www.afnic.fr ?
http://www.afnic.fr
Communication
non chiffre
Diffrents types
dattaques possibles
lors de cette
communication
3
nonc du problme
Infrastructure cl publique X.509 (PKIX)
En revanche, il existe une possibilit quun imposteur publie sa cl publique et se fasse passer pour la banque
dAlice. Alice va chiffrer le message en utilisant la cl publique prsente par limposteur et lenvoyer sa banque,
o limposteur agit comme intercepteur (man-in-the-middle) et copie le message. tant propritaire de la cl
publique, limposteur possde galement la cl prive lui permettant de dchiffrer et de lire le message. Pour faire
une analogie avec la navigation sur le Web, nimporte qui peut crer une cl publique pour accder nimporte
quel nom de domaine. En termes de scurit, cest une catastrophe, car un imposteur peut crer une cl publique
pour des domaines tels que www.example.com, et tromper lutilisateur en le faisant accder un serveur frau-
duleux.
Il est donc ncessaire dtablir un lien entre lidentit (le nom de domaine) et la cl publique. La norme X.509
propose par lUIT et lISO propose un mcanisme permettant de lier une cl publique particulire une identit
particulire. Cette liaison peut tre tablie de manire autonome par le titulaire du nom de domaine et lon parle
dans ce cas dun certifcat auto-sign. Si lapplication qui, pour lauthentifcation, utilise le certifcat auto-sign la
obtenu auprs dune source fable, alors le certifcat est accept ; dans le cas contraire, il ny a aucune garantie
dauthenticit du certifcat.
Rle des Autorits de Certifcation (AC)
Cest l que la ncessit dun tiers de confance se pose. Cest comme dans le cas du passeport, o le tiers de
confance est le gouvernement qui a dlivr le passeport. Dans un passeport, le gouvernement atteste que la
personne sur la photo est identife par un nom et un prnom particuliers et dautres informations didentifcation.
Dans le cas de la navigation sur le Web, le certifcat dlivr fait offce de passeport. Dans lcosystme PKIX, le
rle du gouvernement est jou par des organisations appeles AC. Un certifcat mis par une AC associe le nom
de domaine donn des informations telles que lentit ayant attribu le certifcat, lentit qui en a fait la demande,
la priode de validit du certifcat, etc.
1
Le chiffrement et le dchiffrement des donnes dans le protocole TLS seffectuent au moyen dune paire de cls
cryptographiques : une cl publique et une prive. Les donnes chiffres avec une cl publique ne peuvent tre
dchiffres quavec la cl prive correspondante, et vice versa. Cela permet davoir une communication scuri-
se avec des utilisateurs inconnus. Par exemple, une banque publie sa cl publique et permet quiconque de la
tlcharger. Titulaire dun compte la banque, Alice chiffre un message laide de la cl publique et lenvoie la
banque. Seule la banque est en mesure de dchiffrer ce message avec sa cl prive. Ainsi Alice est sre que son
message ne sera pas lu par quelquun dautre.
Dans une connexion TLS, le navigateur demande au serveur Web denvoyer sa cl publique. La cl publique
envoye par le serveur Web au navigateur est sous la forme dun certifcat X.509, qui est explique plus en dtail
dans la section II.
4
De la mme manire quun passeport dlivr par un gouvernement est accept par dautres gouvernements en
tant que document valide permettant dauthentifer une personne, les diteurs de navigateurs, tels que Firefox,
Chrome, Internet Explorer, Safari, etc., acceptent les certifcats numriques tablis uniquement par certaines
autorits de certifcation. Les diteurs de navigateurs nautorisent une organisation devenir une AC quaprs
stre assurs que cette organisation est digne de confance et quelle observe des principes et des procdures
bien dfnis en ne dlivrant des certifcats quaux titulaires offciels de noms de domaine. Lorsque les diteurs de
navigateurs autorisent une organisation devenir une AC, cette dernire est ajoute la liste des AC de confance
dans la bibliothque du navigateur. Ainsi, lorsquun client utilisant un navigateur accde un nom de domaine
qui dispose dun certifcat numrique gnr par lune des AC fgurant dans sa liste prinstalle, le certifcat est
automatiquement accept comme le montre la Figure 2.
Fig. 2 : La communication entre le navigateur et le serveur
Web est scurise en utilisant lcosystme PKIX et TLS,
mais des attaques restent toutefois possibles
1
IP adress of the
domain requested
192.134.4.20
www.afnic.fr ?
https://www.afnic.fr
1
Adresse IP
du domaine
demand
2
3
Une attaque
est possible en
compromettant lune
des AC de la liste, en
gnrant un certifcat
pour le domaine
concern et en
envoyant ce certifcat
au client avant que
celui-ci ne reoive le
certifcat original.
Diffrents types
dattaques possibles
lors de cette
communication
Le navigateur valide le certifcat
dlivr par lAC (si celle-ci
fgure dans sa liste par dfaut)
mentionne dans le certifcat
Obtient le certifcat
Web pour commencer
la communication
scurise
4
Une connexion chiffre
scurise est tablie avec TLS
5
Le problme des AC nombreuses
En bref, si lon regarde la longueur de la liste des AC reconnues par les navigateurs les plus courants comme
Chrome, Firefox, Internet Explorer, etc., celle-ci varie, mais est de lordre de plusieurs centaines. Par exemple,
un navigateur tel que Firefox reconnat 1 482 certifcats dAC (selon lobservatoire SSL
1
de lEFF) fournies par 651
organisations. Sajoute au problme lexistence dune pratique, au sein de lcosystme des AC, consistant pour
une AC autoriser dautres organisations, ou ses succursales, gnrer des certifcats en son nom. Ces orga-
nisations ou succursales sont appeles des AC subordonnes. Un navigateur reconnatra galement le certifcat
numrique cr par une AC subordonne.
Mme si une seule AC dans la liste des autorits de certifcation est compromise, ou ses subordonnes, elle peut
gnrer un certifcat pour un nom de domaine qui pourrait tre authentif par un navigateur tel que Firefox et
compromettre ainsi la communication Web scurise dun utilisateur fnal utilisant Firefox. Par exemple, deux AC
diffrentes (dont lune est compromise) peuvent mettre deux certifcats diffrents pour le mme domaine et ces
deux certifcats seront accepts par le navigateur. La faille rside dans le fait que jusqu prsent le titulaire dun
domaine navait aucun moyen dindiquer au monde quels AC ou certifcats devaient tre utiliss pour authentifer
la connexion au serveur dun domaine particulier.
Ncessit dune solution
Lutilisation de PKIX pour scuriser les communications Web nest pas nouvelle. Les diteurs de navigateurs,
utilisateurs et organismes de normalisation sont tous conscients du problme - Problme des AC nom-
breuses. Il y a eu quelques tentatives dattnuation du problme (Perspectives, ToFU (Trust on First Use),
Channel ID, Certifcate Transparency, etc.), mais ces tentatives sont devenues plus cibles aprs les deux
attaques de haut niveau sur les AC Comodo et DigiNotar.
La chronologie des vnements est la suivante. Comodo a dcouvert que lune de ses Autorits denregistrement
2
(AE) afflies avait t compromise le 15 mars 2011 et que lattaquant avait cr un compte utilisateur avec lAE
afflie. Avec ce compte, lattaquant a cr des Demandes de signature de certifcat pour des sites Web de grande
valeur tels que login.live.com, mail.google.com, login.yahoo.com etc. et lon croit quil a obtenu au moins un cer-
tifcat public X.509 pour ces sites ( partir de ses 9 demandes).
Sans entrer dans les aspects politiques de cette attaque, un attaquant ayant cr des certifcats frauduleux,
comme dans le cas de Comodo, pourrait agir comme intercepteur (Man-in-the-middle) et rediriger lutilisateur vers
un faux serveur ressemblant celui du site dorigine (hameonnage ou phishing). Les certifcats fournis par le faux
serveur seront accepts par le navigateur, car ils sont gnrs par une AC reconnue par le navigateur. Tout ce
que lutilisateur lit ou crit (nom dutilisateur, mot de passe, email, etc.) peut tre vu et copi par le faux serveur.
1
https://www.eff.org/observatory
2
Les AE recueillent et vrifent les informations didentit provenant dAbonns Directs laide de procdures mettant en uvre les politiques de validation diden-
tit. Les AE crent les Demandes de Signature de Certifcat pour soumission une AC. LAC signe les Demandes de signature de certifcat et dlivre les certifcats
publics X.509 aux abonns directs.
6
Selon les rapports, le pirate qui a pntr dans Comodo est galement parvenu sintroduire dans les systmes
DigiNotar. Bien que lattaque ait t rvle au public la fn aot 2011, lenqute montre que lintrus accdait
au systme DigiNotar depuis le 17 juin 2011. Tout comme dans le cas de lattaque Comodo, lintrus a cr des
certifcats numriques frauduleux pour des sites Web prestigieux. Lenqute rvle galement que les certifcats
gnrs ont t utiliss pour rediriger des utilisateurs vers de faux serveurs et obtenir leurs informations diden-
tifcation.
DigiNotar et Comodo ntaient pas des entreprises ordinaires. Ce sont des socits de scurit de haut niveau
auxquelles de nombreuses organisations, y compris des gouvernements, et des millions dutilisateurs accordent
leur confance. Les attaques ultrieures sur des socits de haut niveau ont montr quil ne sufft pas de renforcer
la scurit de linfrastructure des AC, et ont soulign la ncessit de rduire la porte des attaques dans le modle
PKIX.
Quelles solutions pour rduire la surface dattaque ?
Comme mentionn prcdemment, le problme nest pas la scurit de la technologie PKIX. Mais avec une liste
aussi longue dautorits de certifcation acceptes par les navigateurs par dfaut, il existe une plus forte probabili-
t de compromission lors de ltablissement dune connexion TLS avec PKIX, que lors de la rsolution dadresses
IP avec le DNS. Comme indiqu prcdemment, avec le modle PKIX actuel, un titulaire de nom de domaine na
pas la possibilit dindiquer au navigateur que toute connexion dun utilisateur son domaine doit tre valide par
un certifcat dlivr par une AC particulire.
Diffrentes techniques ont t proposes pour rduire la probabilit dattaque au sein du modle PKIX, telles que
Trust on First Use (ToFU), Perspectives
3
, Certifcate Transparency
4
(CT), Certifcate Authentication and Authoriza-
tion (CAA)
5
et DANE.
Parmi les diffrentes technologies proposes pour limiter la surface dattaque, ToFU est la plus facile mettre
en uvre car il sufft dinstaller un module de navigateur compatible ToFU. Perspectives et CT reposent sur un
systme de service de notarisation qui ne coexiste pas totalement avec le modle PKIX actuel et ncessite des
services supplmentaires agissant comme services de notarisation. CAA est comme une bidouille ne ncessi-
tant aucune modifcation et qui semble court terme une bonne solution pour rduire la surface dattaque. Mais
si lon considre la scurit de faon plus globale et la fourniture doptions supplmentaire aux utilisateurs (telles
que des certifcats auto-signs), DANE arrive en tte.
3
http://perspectives-project.org/
4
http://www.certifcate-transparency.org/
5
http://tools.ietf.org/html/rfc6844
7
2
Une solution permettant de dployer un dispositif de scurit bout-en-bout :
DANE
DANE - Augmenter la scurit dans PKIX
Cette section explique de faon plus dtaille comment DANE rduit la porte dune attaque dans lcosystme
PKIX, en sappuyant sur une infrastructure DNS scurise grce DNSSEC
6
. Avec le protocole DANE, un titulaire
de nom de domaine signe le certifcat fourni par le serveur Web en fonction de diffrentes options (expliques
ci-dessous) et le publie dans la zone DNS du domaine (signe avec DNSSEC), offrant ainsi au titulaire du nom de
domaine la possibilit dinformer lapplication (p. ex. le navigateur) sur les moyens de valider le certifcat prove-
nant du serveur Web. Par exemple, si lAC du domaine www.example.com est X, avec le mcanisme DANE, le
navigateur nacceptera quun certifcat de lAC X pour authentifer le serveur, ce qui rduit ainsi la probabilit
dune attaque.
DANE a t conu et normalis par lIETF. LIETF a publi deux RFC concernant DANE :
1. RFC 6394 Cas dutilisation DANE
2. RFC 6698 - Protocole DANE.
Le RFC 6698 met laccent sur la normalisation et lutilisation de lenregistrement de ressource TLSA. Cet enregis-
trement a pour rle essentiel dtre publi dans une zone DNS et de fournir des informations de certifcat corres-
pondant un service spcifque sur un port spcifque dun nom dans cette zone.

Comme le montre la Figure 3, lenregistrement de ressource TLSA se compose de quatre champs : utilisation
du certifcat, slecteur, mthode de correspondance et certifcat dassociation. Lapplication doit tablir
la correspondance entre le champ de donnes certifcat dassociation de lenregistrement de ressource (RR)
TLSA et le certifcat cible (c.--d. le certifcat fourni par le serveur web du nom de domaine) sur la base des autres
valeurs (utilisation du certifcat, slecteur et mthode de correspondance) fgurant dans lenregistrement de res-
source TLSA.
Le champ Utilisation du certifcat est brivement rsum ici. Pour de plus amples informations sur les autres
paramtres du RR TLSA, veuillez vous rfrer au RFC 6698
Utilisation du certifcat 0/1: si le champ utilisation du certifcat dans le RR TLSA a pour valeur 0 ou 1 , lappli-
cation doit valider le certifcat cible utilisant linfrastructure PKIX, c.--d. valider le certifcat cible en utilisant lco-
systme des AC.
0 - Lors de la validation, le navigateur doit utiliser uniquement lAC spcife dans le champ Certifcat
dassociation du RR TLSA pour valider le certifcat cible.
1 - Le navigateur doit valider le certifcat cible uniquement avec le certifcat mentionn dans le champ
Certifcat dassociation du RR TLSA.
Il y a deux autres valeurs (2 et 3) dans le champ Utilisation du certifcat, qui seront expliques plus loin.
N de port
Protocole
utilis
Slecteur
Usage
Mthode de
correspondance
Certifcat dassociation
443._tcp.dane.rd.nic.fr. IN TLSA 3 0 1 c68ebcc998fda83222cabf2c0228ecc413566e709e5dc5cf25396a8bf4342dd3
Fig. 3 : Explication des enregistrements DNS : TLSA
6
Voir description de ce mcanisme plus loin
8
Pourquoi DNSSEC est-il vital pour DANE ?
Les valeurs 0 et 1 du champ utilisation du certifcat indiquent comment la surface dattaque peut tre rduite
au sein de lcosystme PKIX en validant le certifcat cible fourni par le serveur. Supposons que lattaquant ait
lanc une attaque de type Man in the middle lors de la rsolution DNS (premire opration de la fgure 3) et
fourni une adresse IP frauduleuse pour le domaine demand, le navigateur utilisera ladresse IP obtenue pour
accder au serveur. Si lattaquant cre un certifcat numrique pour le faux serveur partir dune AC autorise,
lattaquant peut convaincre le navigateur quun serveur choisi par lattaquant lui-mme reprsente lgitimement
le service de la victime.
DNSSEC
7
permet un utilisateur de vrifer, sur la base dune chane de confance cryptographique, que les
informations rsultant dune requte de rsolution DNS proviennent de la zone DNS lgitime correspondant au
nom de domaine demand. En dautres termes, lorsquelles sont utilises de bout-en-bout dans le processus de
rsolution DNS, les extensions DNSSEC empchent que les donnes ne soient altres lorsquelles redescendent
jusqu lutilisateur demandeur. Par consquent, pour que DANE augmente la scurit au sein du modle PKIX
existant, les informations obtenues lors de la rsolution DNS doivent tre valides avec DNSSEC. Cest pourquoi
le RFC 6698 (protocole DANE) stipule que la zone DNS qui a un RR TLSA doit tre signe par DNSSEC et que les
applications qui interrogent le domaine pour validation du RR TLSA doivent utiliser un rsolveur DNSSEC. Pour
simplifer, DANE nest effcace que sil repose sur une infrastructure DNSSEC.
Ainsi DANE combin DNSSEC offre une scurit de bout-en-bout aux deux tapes dune communication Inter-
net (comme le montre la Figure 4) : tout dabord lors de la rsolution DNS prliminaire, puis lors de la connexion
tablie avec le serveur du domaine.
7
http://tools.ietf.org/html/rfc6698/
Fig. 4 : Possibilits de compromission dune
communication scurise considrablement
rduites grce DANE & DNSSEC
Une attaque
nest possible
quen modifant
linformation contenue
dans la zone DNS
du domaine ou
un de ses parents.
1
IP adress of the
domain requested
3
Le navigateur utilise les
informations provenant du
RR TLSA pour valider le
certifcat cible
Avec TLS, la communi-
cation de donnes entre
le navigateur et le
serveur Web est chiffre
2
1
Adresse IP et
enregistrement
TLSA du domaine
demands avec
DNSSEC
Avec DNSSEC, falsif-
cation et modifcation
de donnes seront
dtectes
Obtient le certifcat Web pour
commencer la communication scurise
9
DANE - Utilisation de DNSSEC comme PKI alternative
Jusqu prsent, lattention tait porte sur une infrastructure cls publiques (PKI) reposant sur des certifcats
numriques, savoir le modle PKIX. Le DNS complt par les extensions DNSSEC devient de facto une PKI.
Comme dans le cas du modle PKIX, o la cl de lAC est lancre de confance, dans le cas du PKI DNSSEC,
lancre de confance est la cl de la racine du DNS.
Les valeurs 2 et 3 du champ utilisation du certifcat indiquent comment une scurit de la navigation sur le
Web peut tre instaure de bout-en-bout sans que lcosystme des AC entre en jeu. Autrement dit, un titulaire
de domaine cre un certifcat auto-sign et peut toutefois tre authentif par les diteurs de navigateurs :
2 en cas dutilisation indique quune organisation a prvu de crer sa propre AC et que tous les dpartements
de cette organisation crent leurs propres certifcats avec lAC cre comme ancre de confance de leurs
sites Web respectifs. Lors de la validation, normalement le navigateur ne reconnatra pas le site Web des
dpartements de lorganisation, car lAC de lorganisation ne fgure pas dans sa liste des AC de confance.
Mais, en recevant le RR TLSA dans la rponse aprs validation DNSSEC, il est certain que les donnes de
lenregistrement TLSA ne sont pas contrefaites, sauf si quelquun a accs la zone DNS du domaine. Pour
valider le certifcat, le navigateur doit sassurer que lAC du certifcat cible est la mme que celle indique dans
le champ Certifcat dassociation du RR TLSA.
3 en un cas dutilisation indique que ladministrateur de domaine dlivre le certifcat auto-sign qui est stock
comme certifcat cible sur le serveur web, et quune empreinte du certifcat est ajoute dans la zone DNS du
domaine dans le champ certifcat dassociation du RR TLSA. Pour valider le certifcat, le navigateur doit
sassurer que le certifcat cible correspond au champ Certifcat dassociation du RR TLSA.
Ainsi, la technologie DANE renforce non seulement la scurit de la navigation Web sur le dernier kilomtre en
utilisant le modle PKIX existant, mais fournit galement une solution alternative consistant nutiliser quun DNS
renforc par DNSSSEC et donc contourner compltement le mcanisme de fourniture et de gestion des certi-
fcats X.509 via PKIX.
Mettre en uvre DANE
La premire tape vers la mise en uvre DANE pour un nom de domaine est de crer un enregistrement TLSA
pour le domaine, par ladministrateur du domaine. Il existe plusieurs outils disponibles pour gnrer un enregis-
trement TLSA. Lun deux est SWEDE
8
. Lenregistrement TLSA gnr est publi dans la zone DNS par ladmi-
nistrateur du domaine, et la zone a t signe avec DNSSEC.
Au cours de rsolution DNS, lenregistrement TLSA devrait galement tre interrog comme indiqu dans la
Figure 4. Si le champ utilisation de certifcat dans lenregistrement TLSA a des valeurs 0 ou 1 , lapplication
doit valider le certifcat cible en utilisant linfrastructure PKIX (voir III.1). Si le champ utilisation de certifcat dans
lenregistrement TLSA a des valeurs 2 ou 3, alors la validation est faite en utilisant linfrastructure DNS renforc
par DNSSEC (voir III.3).
8
https://github.com/pieterlexis/swede
10
En conclusion : DANE ou la pice jusqu prsent manquante au dispositif
de scurisation de bout-en-bout de lInternet ?
DANE nest pas rserv qu la navigation sur le Web
DANE a t conu pour rsoudre les problmes relatifs la navigation sur le Web. Des efforts ont t dploys
lIETF au sein du groupe de travail DANE
9
pour en tendre lutilisation la scurisation dautres applications
comme la messagerie lectronique (s/MIME), la messagerie instantane (XMPP), etc. Tous ces travaux se pour-
suivent et sils sont adopts par lIETF et publis en tant que RFC, des implmentations suivront. DNSSEC est une
infrastructure indispensable commune pour toutes ces implmentations.
Rle de DANE dans lacclration du dploiement de DNSSEC
Comme expliqu au dbut du prsent document, une communication Internet type implique lcosystme DNS
pour rsoudre ladresse dun nom de domaine particulier. DNSSEC permet de sassurer que les donnes obte-
nues par rsolution DNS proviennent de la zone lgitime du nom de domaine (authentifcation de lorigine des
donnes) et que les donnes ne sont pas altres lors du transfert (intgrit des donnes). Ces extensions de
scurit font de DNSSEC une composante essentielle des communications Internet ncessitant un haut niveau
de confance dans linfrastructure DNS.
Comme la plupart des technologies importantes (telles que IPv6), DNSSEC illustre le paradoxe de luf et de la
poule. De nombreux fournisseurs de services et dinfrastructure rseau adoptent une position attentiste lgard
de DNSSEC. Les raisons invoques sont variables et vont de la complexit de mise en uvre de DNSSEC aux
pannes injustifes et incitations commerciales. Beaucoup dentre eux sont prts attendre un scnario qui les
obligera dployer DNSSEC dans leur infrastructure rseau.
Ladoption lente de DNSSEC a souvent t attribue labsence dapplication phare utilisant DNSSEC comme
base de la scurit. Le potentiel commercial gnr par une telle application peut induire une pression des
consommateurs pour ladoption de DNSSEC. Mme si les applications construites autour de DNSSEC et du
protocole DANE peuvent ne pas tre des applications phares pour DNSSEC, leur mise en uvre de manire
transparente assurera la scurit de millions dutilisateurs utilisant Internet pour des communications scurises.
Lutilisation mme de ces applications par des millions dutilisateurs exigeant une infrastructure rseau scurise
par DNSSEC forcera les parties prenantes dployer DNSSEC. Ainsi, DANE pourrait tre un catalyseur acclrant
ladoption de DNSSEC
3
9
https://datatracker.ietf.org/wg/dane/charter/
Retrouvez tous les dossiers thmatiques de lAfnic :
http://www.afnic.fr/fr/ressources/publications/dossiers-thematiques-7.html

Dossier Thematique12 VF1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dossier Thematique12 VF1

Transféré par

Droits d'auteur :

Formats disponibles

Dossier thmatique n12

Vous aimerez peut-être aussi