Skip to main content

DNSSEC : roulement de la clé de signature de clé de la zone racine

Ksk rollover 750x480 22jul16 fr

L'ICANN a publié aujourd'hui des plans pour mettre à jour ou « rouler » la clé de signature de clé de la zone racine (KSK), marquant une nouvelle étape importante dans nos efforts continus visant à améliorer la sécurité du système des noms de domaine (DNS).

Les plans de roulement de la KSK ont été développés par les partenaires de la gestion de la zone racine : l'ICANN, dans le cadre de son rôle d'opérateur des fonctions IANA, Verisign, en tant que responsable de la maintenance de la zone racine et l'Administration nationale des télécommunications et de l'information (NTIA) du Département du commerce des États-Unis en tant qu'administrateur de la zone racine. Les plans intègrent les recommandations de mars 2016 [PDF, 1.01 MB] de l'équipe de conception du roulement de la KSK de la zone racine, après qu'elle a demandé et analysé les commentaires du public sur un processus de roulement proposée.

Qu'est-ce que la KSK ?

La KSK est une paire de clés cryptographiques publique-privée qui joue un rôle important dans le protocole des extensions de sécurité du système des noms de domaine (DNSSEC). La partie publique de la paire de clés est le point de départ fiable pour la validation de DNSSEC, semblable à la manière dont la zone racine sert comme point de départ pour la résolution du DNS. La partie privée de la KSK est utilisée au cours des cérémonies KSK de la racine pour signer les clés de signature de zone utilisés par Verisign pour signer le DNSSEC de la zone racine.

Pourquoi rouler la KSK ?

L'hygiène de sécurité recommande que les mots de passe soient modifiés périodiquement dans le but de réduire le risque que ces mots de passe puissent être compromis par des attaques de force brute. Comme c'est le cas avec les mots de passe, la communauté nous a informés que les clés cryptographiques utilisées pour signer la zone racine devraient être périodiquement changées afin d'aider à maintenir l'intégrité de l'infrastructure qui dépend de ces clés et ainsi assurer que les meilleures pratiques de sécurité soient respectées.

Le processus de roulement de la KSK

Le roulement de la KSK implique la création d'une nouvelle paire de clés cryptographiques qui sera utilisée dans le processus de validation de DNSSEC afin de vérifier que les réponses aux requêtes de noms dans la zone racine (généralement les TLD) n'aient pas été modifiées en transit. La transition vers cette nouvelle paire de clés et le retrait de la paire de clés actuelle fait également partie du processus de roulement. Les fournisseurs de services Internet, les opérateurs de réseaux d'entreprise et d'autres ayant permis la validation de DNSSEC doivent mettre à jour leurs systèmes avec la nouvelle partie publique de la KSK, connue comme « l'ancre de confiance » de la racine. Le non-respect de cette action signifie que les validateurs compatibles-DNSSEC ne seront pas en mesure de vérifier que les réponses DNS n'aient pas été faussées, ce qui signifie que les résolveurs de validation de DNSSEC renverront une réponse d'erreur à toutes les requêtes.

Étant donné que c'est la première fois que la paire de clés de la KSK sera changée depuis qu'elle a été générée en 2010, un effort coordonné de la communauté Internet s'avère nécessaire afin d'assurer avec succès que toutes les parties concernées aient la nouvelle partie publique de la KSK et soient au courant de l'événement de roulement de la clé. L'ICANN discutera du roulement de la KSK dans divers forums techniques et utilisera le hashtag #KeyRoll pour rassembler le contenu, faire des mises à jour et répondre aux requêtes dans les réseaux sociaux. Nous avons également créé une page de ressources spéciale en ligne pour que tout le monde demeure informé des activités liées au roulement de la clé.

Si le roulement de la KSK se termine en douceur, il n'y aura aucun changement visible pour l'utilisateur final. Mais comme avec pratiquement n'importe quel changement sur Internet, il y a une petite chance que certains logiciels ou systèmes ne soient pas en mesure de gérer correctement les changements. S'il y avait des complications généralisées, les partenaires de la gestion de la zone racine peuvent décider que le roulement de la clé doit être annulé afin que le système retrouve un état stable. Nous avons élaboré des plans détaillés qui nous permettront de faire marche arrière avec le roulement de la clé dans une telle circonstance.

Délais

Le roulement de la KSK se déroulera en huit étapes, qui devraient durer environ deux ans. La première étape devrait débuter au 4e trimestre de 2016.

Prochaines étapes

Les développeurs de logiciels prenant en charge la validation de DNSSEC devraient s'assurer que leur produit supporte la RFC 5011. Dans ce cas, la KSK sera mise à jour automatiquement, le moment venu. Pour un logiciel qui n'est pas conforme à la RFC 5011, ou pour un logiciel qui n'est pas configuré pour l'utiliser, le nouveau fichier de l'ancre de confiance peut être mis à jour manuellement. Ce fichier sera disponible ici et il devrait être récupéré avant le démarrage du résolveur et une fois que la KSK aura été changée dans l'ensemble d'enregistrements de ressources DNSKEY (RRset) de la zone racine du DNS.

L'ICANN a élaboré des tests opérationnels auxquels les développeurs de logiciels et les opérateurs des résolveurs de validation peuvent accéder afin de déterminer si leurs systèmes sont préparés pour le roulement de la KSK. Pour mieux connaître ces tests, cliquez ici [PDF, 519 KB].

Comme le roulement de la KSK s'approche, toutes les parties intéressées peuvent en savoir plus et obtenir les mises à jour à https://www.icann.org/kskroll. Veuillez partager cette ressource avec d'autres et les encourager à mieux connaître ces changements à venir pour le DNS.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."