In mid-October 2024, a new root signing ceremony was held, this time with three objectives:

• the normal one, which is to sign the upcoming ZSKs for the first quarter of 2025;
• change to one of the TCRs. Frederico Neves, the director of Registro.BR from Brazil, is stepping down. He has been with us since the first ceremony. We thank him for all the time dedicated and his contributions to improving the ceremonies from the beginning. His replacement will be George Michaelson from APNIC, Australia.
• include the new KSK-2024 in the DNSKEY set of the first quarter of 2025, thus initiating the key rotation phase. On January 11, 2025, this new KSK should be published alongside the current one, but the keyset will still be unsigned.

Additionally, a set was signed in case it was necessary to withdraw the new key. This is in case of any emergency, for example, if publishing the new key causes some resolvers to have issues due to the new size. It is unlikely, this is the third rotation in history, and the others had no problems. But it is very important to have an “escape plan” for any emergency.

The new KSK-2024 key has the following DS hash and public key:

. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
. IN DNSKEY 257 3 8 (
         AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jB
         osZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnh
         athWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZO
         T4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9m
         R7K2vaF18UYH9Z9GNUUeayffKC73PYc=
         )

that you can verify on the official IANA site in various formats.

Additionally, a new operating system (coen-2.0.0) was launched that allows controlling the HSMs, which this time manages both models at the same time (remember that starting this year (in spanish only), Luna devices began to be used which will be the replacement for the original Keyper in the future). Although this time it was not necessary to sign with the new Luna, in the following ceremonies they will be used in parallel, signing with both at the same time. This will be necessary until the key rotation is completed, in a couple of years. After that, the Keyper will be decommissioned, and only the Luna will be used.

Once again, I wanted to thank the tremendous work of the “Root Zone KSK Operations Security” officials, Andrés and Aaron, who managed to schedule an impeccable ceremony!

A mediados de octubre de 2024 se realizó una nueva ceremonia de firma de la raíz, esta vez con tres objetivos:

• el normal, que es firmar las próximas ZSK del primer trimestre de 2025;
• cambiar a uno de los TCR. Se retira Frederico Neves, el director de Registro.BR de Brasil. El estuvo desde la primera ceremonia. Le agradecemos todo el tiempo dedicado y sus aportes en mejorar las ceremonias desde los inicios. Su reemplazo será George Michaelson, de APNIC, Australia.
• incluir la nueva KSK-2024 en el DNSKEY set del primer trimestre de 2025, para así dar por iniciada la etapa de rotación de llave. El día 11 de enero de 2025 debiera aparecer publicada esta nueva KSK junto con la actual, pero aún sin firmar aún el keyset.

Además se firmó un set en el caso que fuera necesario retirar la nueva llave. Esto es en el caso de alguna emergencia, por ejemplo que al publicar la nueva llave algunos resolvers tengan algún problema por el nuevo tamaño. Es poco probable, esta es la tercera rotación en la historia, y las otras no tuvieron problemas. Pero es muy importante tener un “plan de escape” por cualquier emergencia.

La nueva llave KSK-2024 tiene el siguiente hash DS y llave pública:

. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
. IN DNSKEY 257 3 8 (
         AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jB
         osZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnh
         athWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZO
         T4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9m
         R7K2vaF18UYH9Z9GNUUeayffKC73PYc=
         )

que pueden verificar en el sitio oficial de IANA en diversos formatos.

Además se estrenó un nuevo sistema operativo (coen-2.0.0) que permite controlar los HSM, que esta vez maneja los dos modelos al mismo tiempo (recuerden que a partir de este año, se comenzó a utilizar dispositivos Luna que será el reemplazo de los originales Keyper en el futuro). Aunque en esta ocasión no fue necesario firmar con los nuevos Luna, en las siguientes ceremonias serán utilizadas en paralelo, firmando con ambas al mismo tiempo. Esto será necesario hasta cuando se termine la rotación de la llave, en un par de años más. Luego de eso, ya se darán de baja las Keyper, y se seguirá solo con las Luna.

Una vez más, quería agradecer el tremendo trabajo de los oficiales “Root Zone KSK Operations Security”, Andrés y Aaron, que lograron programar una ceremonia impecable!

As I shared in the last article about the generation of the new Internet root DNSSEC key, this week it was officially published:

. DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

This is the third DNSSEC root key in history. Recall that the first was in 2010, and the second -which corresponded to the first rollover- was 2016.

As always, the official publication site is that of IANA Trust Anchors and Keys.

For the time being, there is no need for either operators or the public to do anything. It is expected that from now on all DNS software will start to incorporate this new key in their internal stores, and start to be installed with normal software updates. There is still time, the final rollover is planned for October 2026, more than two years from today. In any case, it is expected that a few months before the final rotation, tools will be available to verify that everything is OK.

Tal como compartí en el último artículo acerca de la generación de la nueva llave DNSSEC de la raíz de Internet, esta semana fue publicada oficialmente:

. DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

Se trata de la tercera llave DNSSEC de la raíz en la historia. Recordemos que la primera fue en el año 2010, y la segunda -que correspondió a la primera rotación- fue el año 2016.

Como siempre, el sitio oficial de publicación es el de IANA Trust Anchors and Keys

Por el momento no es necesario que ni los operadores ni el público hagan nada. Se espera que a partir de ahora todos los softwares de DNS comiencen a incorporar esta nueva llave en sus almacenes internos, y se comiencen a instalar con las actualizaciones normales de software. Aún hay tiempo, la rotación definitiva se planea para octubre de 2026, más de dos años a partir de hoy. De todas formas, se espera que unos meses antes de la rotación definitiva aparezcan herramientas que permitan verificar que todo esté bien.

This year I was selected to be one of ICANN’s TCRs, the Trusted Community Representatives, to participate in the DNS Root Signing Ceremony. My particular role is to be Cryptographic Officer, responsible for guarding 1 of the 7 keys that allow access to the KSK.

In this article I want to explain what this job is about, oriented to people without deep technical knowledge in DNS/DNSSEC.

1. What is the root signature about?

DNS is the protocol that allows domain names to function on the Internet. Through DNSSEC, digital signatures can be added to the DNS, so that any message carries a certificate of validity, which can be verified in real time by anyone who has access to those messages.

In this way, the DNS lets you know that www.fao.org is a website located at IP address 104.18.24.133, and DNSSEC adds a digital signature that certifies that the response was created by the World Food and Agriculture Organization, and that it is correct and complete.

For this certification, cryptographic keys are used, pieces of mathematical information that allow that only the authorized person can create signatures, and that anyone on the Internet can be able to verify them. Making a parallel with signatures in the real world, only you can draw your signature (no one can copy your strokes or the way you draw it), and we are all specialized experts who can verify that it is real and correct; and that no one copied it from somewhere else.

The DNS is hierarchical, in the sense that all the information starts from a root, and from there it is distributed to the rest of domain names. Following the example, www.fao.org is a name that is part of the fao.org domain, which in turn is part of the org domain, which is finally part of the root. Each organization is responsible for each label. www.fao.org is created and managed by FAO, whatever happens in org is created and managed by a body called PIR, and whatever happens in the root is managed by ICANN, the body in charge of the DNS root.

This same hierarchy is used for signatures. To verify that the DNS message from www.fao.org has correct signatures, it is checked that the mathematical proof is valid, using the FAO keys. But how do we trust the FAO keys? We have to go to their parent .org, who certifies that the fao.org key is correct. And how do we know that the org key is correct? We go to its parent, the DNS root, which certifies that the org key is correct. And finally, how do we verify that the root key is correct? Here there are no more parents, so this key has to be known all over the Internet. And this is how any computer, server, phone, or any device that uses DNSSEC, must know this last key, mother of all.

So we finally come to answer the original question: what is root signing? It is the creation of keys and digital signatures using cryptographic keys of the DNS root, which is the origin of the verification chain of all domain names on the Internet.

2. What are the ceremonies?

Root signing ceremonies are meetings where DNS root keys are accessed. In some ceremonies, new keys are created, in others the keys are signed, and there are also administrative activities such as backups, copying between different devices, and so on.

As you might suspect, this work has to be done very carefully. The keys are stored in specialized devices, called “HSMs” (Hardware Security Modules), boxes that are capable of generating keys and signing, and have extreme security controls. HSMs have internal devices that prevent them from being opened, knocked, and any physical tampering. In the event of any of these acts, they are automatically erased. To communicate with them, a special protocol is needed, they do not connect to any kind of network, let alone the Internet! Finally, in order to activate the HSMs, smart cards are needed, which are guarded by different people, and a minimum quorum is required to operate. This prevents anyone from activating them on their own, and requires a minimum number of other people, which prevents collusion.

Ceremonies are very controlled activities. Everything that is done must be written in a script, from the entrance to the room to the step-by-step of all activities. This script is available to anyone who wants to review it, and there are different people who audit and certify that it was followed correctly. IANA is certified for two external audits per year.

On the other hand, the HSMs are stored inside anti-intrusion bags, and then inside safes. The safes are inside a cage with restricted access, and this cage is in a special office in a data center guarded by armed guards.

IANA maintains two such facilities, each with a copy of the information. One is on the east coast of the United States (near Washington DC), and the other is on the west coast, in Los Angeles.

3. What is my job there?

The TCRs are selected from different parts of the world, to represent the whole community. Currently there are 4 of us from Latin America, who share different roles and are divided between the two locations where the ceremonies are held.

As indicated in the previous question, to activate the HSM a quorum of smart cards is needed. These cards are guarded by “Cryptographic Officers”, and it is necessary that of the seven officers, at least three are present to activate them.

That is why my job as CO is to attend the ceremonies, present the card to the ceremony administrator, and certify that the activities that take place are faithful to the script. Finally, it is also important to make sure that the HSMs are deactivated after use, stored properly in their bags and safes, and guard the card until the next ceremony.

4. Where can I learn more?

IANA maintains a site where all the policies, procedures, and scripts that control root signing ceremonies are publicly available: IANA DNSSEC Information.

You will also find the material for each ceremony, including the script with written notes, and a video of the entire activity! This video is streamed in real time and anyone can follow it, and there is even an expert present to answer your comments, so you can take advantage of the opportunity to ask questions right there.

5. This all looks like something out of a movie, doesn’t it?

Of course there was quite a stir about “the seven keys that control the Internet” :) There are quite a few press releases and articles, some more accurate than others.

And actually it has already appeared in some episodes of series ;)

Here’s a scene from the 2017 series “The Blacklist Redemption”, and another from “Elementary”.

There was also a visit from a famous Youtuber, who made a couple of notes.

And on a more serious side, the BBC made a documentary, of which I only got the first few seconds.

La ceremonia de firmado de la raíz del DNS número 53, llevada a cabo en el mes de abril de 2024, se trató de una ocasión especial por dos motivos: se inauguraron los nuevos dispositivos criptográficos (HSM) que reemplazarán a los que se estaban utilizando desde la primera ceremonia; y además se creó la nueva llave KSK que reemplazará a la actual en funcionamiento.

¿Qué es una ceremonia de firma de la raíz? Revise el artículo anterior con una introducción.

Debido al cambio de los HSM, además se necesitó que por primera vez estuviéramos todos los Oficiales Criptográficos presentes (siete personas), y todos los Portadores de Llaves de Recuperación (siete personas más). Esta reunión de todos los TCR no ocurría desde la primera ceremonia de raíz, el año 2010.

Esto ocasionó que las ceremonias se repartieran en dos días, de 6 y 9 horas de duración cada una. Esta última representa un record de duración, superando el anterior que ostentaba la primera ceremonia (cercana a las 8 horas).

Como siempre, toda la ceremonia se transmite en vivo por streaming, y quedan disponibles los videos y todos los documentos para su revisión por quien quiera, en el sitio de IANA.

Mención especial a la gente que está en remoto acompañándonos. Debo confesar que yo lo intenté varias veces en años anteriores, pero nunca pude hacerlo completo. Es distinto en persona… aunque nadie me cree, ¡en realidad se hacen mucho más cortas y entretenidas!

Nuevos HSM

Tal como fuera anunciado en el artículo anterior de la ceremonia 51, el año pasado se recibió la noticia que el fabricante de los dispositivos HSM que eran utilizados desde el año 2010 (Keyper Plus HSM) iban a abandonar esa línea de productos. Como se debe considerar que la llave raíz se mantiene firmando aproximadamente de 5 a 10 años, un cambio de esta naturaleza significa reemplazar todos los dispositivos y elegir un nuevo proveedor. Luego de un estudio de varios meses llevado a cabo por IANA, la decisión fue cambiarse por el dispositivo Thales Luna USB HSM 7, que cumple con altos estándares de seguridad (FIPS 140-2/-3 level 4) y otra serie de requerimientos específicos del tipo de uso y ceremonias que realizamos. Acá se encuentra un estudio detallado de comparación de distintos hardware, y otros caminos posibles que se evaluaron para reemplazar los Keyper.

En definitiva, los nuevos HSM son más pequeños, rápidos y con mejor usabilidad. Tienen una pantalla LCD a color y una interfaz más moderna. La conexión al equipo controlador es vía USB, comparado con el puerto serial de los Keyper. Quizás se extrañará lo imponente de los antiguos, con su caja de gran tamaño y aspecto militar, además del miedo de operarlos por sus características de autodestrucción frente a golpes y diversas intervenciones físicas. Los nuevos sólo parecen un celular gordo ;)

Cada HSM nuevo tiene su copia exacta en las mismas instalaciones, y un clon con su propia copia en las instalaciones de la costa Oeste. Además existen unos “HSM de backup” que se ven iguales, pero solo permiten respaldar la llave sin capacidad de firmar. Estas también se encuentran cada una en las dos instalaciones.

Los HSM al igual que los anteriores requieren de una serie de dispositivos para activarse y ser operados, que es donde aparecemos los TCR. Los Portadores de Llaves de Recuperación se llevan sus trozos y los guardan durante años, en la eventualidad que sea necesario recuperar las HSM; y los Oficiales Criptográficos guardamos los trozos que permiten realizar las firmas, por lo que debemos reunirnos 4 veces al año para la mantención normal de la zona raíz. Otra novedad es que estos dispositivos son ahora parecidos a pendrives USB, comparados con las tarjetas smartcards de los Keyper.

Las ceremonias se llevaron a cabo sin problemas, con una gran cantidad de acciones (formatearlas, definición de roles, particiones, creación de llaves de TCRs, clonados, etc). Un aplauso para la gran labor que realizan los administradores de las ceremonias; Aaron Foley y Andrés Pavez, que tienen cada detalle solucionado de antemano. Es una tremenda labor de planificación y programación del cual solo vemos el final feliz.

Al finalizar la ceremonia 53 quedan algunos dispositivos que deben ser trasladados a las instalaciones de la costa Oeste, por lo que todo el proceso culmina una vez que son depositados ahí, y son activados y verificados por los TCR de allá.

Nueva KSK

Como no es posible copiar la actual KSK a los nuevos HSM, y felizmente calzando con la programación de rotación de la llave, se aprovechó de generar la nueva KSK que reemplazará a la actual en los recién estrenados HSM. Se mantuvo el mismo tipo de llave, una RSA/SHA256. Se espera que esta nueva llave sea publicada a fines de este año 2024, y la rotación se realice a fines del 2026. Los dos años permitirán que todos los resolvers del mundo alcancen a actualizar sus configuraciones. Cabe recordar que esta será la segunda rotación de la historia. La primera se hizo el año 2017, cuando se reemplazó la llave original del 2010. En esa ocasión todo funcionó bien, solo hubo pequeños problemas específicos en ciertos operadores, por lo que ahora se espera que los dos años de plazo, sumado a las mejoras en la tecnología de los resolvers, y a la mayor conciencia que hay en DNSSEC, hagan que ojalá resulte aún más fácil.

La nueva llave se publicará una vez que se esté seguro que se trasladó sin problemas a la costa Oeste, en la ceremonia número 54. Será publicada en el sitio oficial de IANA como siempre en diversos formatos, y se espera que desde entonces comience a aparecer en las actualizaciones de software de los distintos resolvers y autoritativos.

Mientras tanto las ceremonias de los próximos años se deben seguir haciendo con los HSM antiguos, hasta terminar la rotación.

Si usted es operador, no se preocupe (todavía). Cuando actualice su versión de DNS, debiera automáticamente aparecer la nueva llave. Y de seguro al acercarse la fecha de rotación el 2026, habrá campañas, procedimientos y herramientas para revisar que todo está bien.

Este año fui seleccionado para ser uno de los TCR de ICANN, los Representantes de Confianza de la Comunidad, para participar de la ceremonia de la firma de la raíz del DNS. Mi rol en particular es ser Cryptographic Officer, responsable de custodiar 1 de las 7 llaves que permiten acceder a la KSK.

En un artículo anterior escribí más detalles introductorios de qué es esta ceremonia, por qué se firma la raíz del DNS, cuál es mi labor, etc.

Durante la ceremonia número 51, realizada a fines de noviembre de 2023 en las instalaciones de la costa Este de Estados Unidos, se realizó la firma de las ZSK del primer semestre de 2024, que es la actividad habitual y normal. Además se aprovechó de agregar dos nuevos dispositivos HSM, para aprovechar de renovar los más antiguos que cumplieron el ciclo de vida del fabricante.

Por otro lado, en una ceremonia anterior, se aprovechó de cambiar a uno de los TCRs antiguos, Christopher Griffiths que estuvo 10 años en el puesto, y fue reemplazado por Nomsa Mwayenga de Sudáfrica.

La ceremonia funcionó sin problemas y aunque fue más larga de lo normal (3 horas y media), se logró realizar el guión en su totalidad.

Participamos 5 TCR de los 7 disponibles, incluyendo la nueva TCR recién incorporada. Además hay participantes de IANA e ICANN que van de testigos, y encargados de la operación de la ceremonia, de empresas de auditoría, de Verisign quien es responsable de entregar las ZSK que se firmarán, y dos personas externas (de SANS Institute y de Capital One) que solicitaron participar. Cualquier persona puede solicitar participar de una de estas ceremonias en calidad de testigo externo, y dependiendo del espacio y logística, son bienvenidas a asistir.

Además en estas ceremonias se aprovecha de verificar que todos los dispositivos criptográficos estén funcionando correctamente (llaves, smartcards, HSMs, etc), verificar que ni las cajas fuertes ni las bolsas de evidencia hayan sido manipuladas, entre otras actividades administrativas.

Aprovechamos también de conversar acerca de la noticia que los actuales HSM quedarán fuera soporte y stock, porque la empresa que los fabricaba cerró esa línea de negocio. Esto ocasionó un análisis de alternativas en IANA, considerando el riesgo de mantener las actuales HSM sin posibilidad de cambio. Cualquier alternativa de cambio de fabricante de HSM significa necesariamente regenerar las llaves KSK, porque por su naturaleza no permiten copiar la llave de una a otra. La opción sería comprar HSM de otra marca y volver a generar una KSK nueva, para hacer la rotación desde la llave actual en los HSM actuales, a esta nueva llave en los HSM nuevos. De ser así, la última KSK generada en la ceremonia 49 de abril de este año (id 46211), que fue hecha en los HSM actuales para reemplazar la actual KSK en funcionamiento desde 2017, y que aún se mantiene guardada sin comenzar su proceso de rotación, nunca vería la luz y sería abandonada.

Se espera que a comienzos del 2024 IANA tenga el plan completo, el cual será sometido a discusión y seguramente a evaluación y comentarios de toda la comunidad.

Por último, cumpliendo mi papel de TCR a nombre de la comunidad, certifico que la actividad se llevó a cabo de forma correcta, cumpliendo con los pasos del guión, sin compromiso de la KSK y con participación de distintos actores de la comunidad. Se firmaron los keysets del primer trimestre de 2024 (rotación de ZSK desde 46780 a 30903) que aparecerán en la zona raíz en los meses que siguen, se reemplazó a un Cryptographic Officer, y se incorporaron dos HSM nuevos que reemplazarán a los más antiguos.

Todo el material de la ceremonia, incluída la transmisión completa que se realiza públicamente en tiempo real a través de YouTube, está disponible en el sitio web de IANA.

Este año fui seleccionado para ser uno de los TCR de ICANN, los Representantes de Confianza de la Comunidad, para participar de la ceremonia de la firma de la raíz del DNS. Mi rol en particular es ser Cryptographic Officer, responsable de custodiar 1 de las 7 llaves que permiten acceder a la KSK.

En este artículo quiero explicar de qué se trata esta labor, orientado a gente sin conocimientos técnicos profundos en DNS/DNSSEC.

1. ¿De qué se trata la firma de la raíz?

El DNS es el protocolo que permite el funcionamiento de los nombres de dominio en Internet. Mediante DNSSEC, se puede agregar firmas digitales al DNS, de manera que cualquier mensaje lleve una certificación de validez, que puede ser verificada en tiempo real por cualquiera que tenga acceso a esos mensajes.

De esta forma, el DNS permite saber que www.fao.org es un sitio web que se encuentra en la dirección IP 104.18.24.133, y DNSSEC le agrega una firma digital que certifica que la respuesta fue creada por la Organización Mundial para la Agricultura y Alimentación, y que es correcta e íntegra.

Para esta certificación se utilizan llaves criptográficas, trozos de información matemática que permiten que solo la persona autorizada puede crear firmas, y que cualquiera en Internet puede ser capaz de verificarlas. Haciendo un paralelo con las firmas en el mundo real, solo tú puedes dibujar tu firma (nadie puede copiar tus trazos ni tu forma de dibujarla), y todos somos peritos especializados que podemos verificar que es real y correcta; y que nadie la copió de otro lado.

El DNS es jerárquico, en el sentido que toda la información parte de una raíz y desde ahí se va distribuyendo hacia el resto de nombres de dominios. Siguiendo el ejemplo, www.fao.org es un nombre que es parte del dominio fao.org, el que a su vez es parte del dominio org, el que finalmente es parte de la raíz. Cada organización es responsable de cada etiqueta. www.fao.org es creado y administrado por la FAO, lo que pase en org es creado y administrado por un organismo llamado PIR, y lo que pase en la raíz es administrado por ICANN, el organismo a cargo de la raíz del DNS.

Para las firmas se utiliza esta misma jerarquía. Para verificar que el mensaje DNS de www.fao.org tiene firmas correctas, se revisa que la prueba matemática es válida, usando las llaves de FAO. Pero ¿cómo confiamos en las llaves de FAO? Tenemos que ir a su padre .org, quien certifica que la llave de fao.org es correcta. ¿Y cómo sabemos que la llave de org es la correcta? Vamos donde su padre, la raíz del DNS, que certifica que la llave de org es correcta. Y finalmente, ¿cómo verificamos que la llave de la raíz es la correcta? Acá ya no hay más padres, entonces esta llave tiene que conocerse por todo Internet. Y es así como cualquier computador, servidor, teléfono, o cualquier dispositivo que utilice DNSSEC, debe conocer esta última llave, madre de todas.

Entonces llegamos finalmente a responder la pregunta original: ¿qué es la firma de la raíz? Es la creación de llaves y firmas digitales usando llaves criptográficas de la raíz del DNS, que es el origen de la cadena de verificación de todos los nombres de dominio en Internet.

2. ¿Qué son las ceremonias?

Las Ceremonias de firma de la raíz son reuniones en que se accede a las llaves de la raíz del DNS. En algunas ceremonias se crean nuevas llaves, en otras se firma con esas llaves, y también hay actividades administrativas como hacer respaldos, copiarlo entre distintos dispositivos, etcétera.

Como deben sospechar, esta labor hay que hacerla con mucho cuidado. Las llaves se guardan en dispositivos especializados, llamados “HSM” (Hardware Security Modules), cajas que son capaces de generar llaves y firmar, y que tienen controles de seguridad extremos. Los HSM tienen dispositivos internos que evitan que los abran, que los golpeen, y cualquier manipulación física. Ante cualquiera de estos actos, se borran automáticamente. Para comunicarse con ellos, se necesita de un protocolo especial, no se conectan a ningún tipo de red, ¡menos Internet! Por último, para poder activar los HSM se necesita de smartcards (tarjetas inteligentes) que son custodiadas por distintas personas, y se requiere de un quorum mínimo para funcionar. Esto evita que cualquier persona pueda activarlas por sí sola, y necesita de un mínimo de otras personas más, lo que evita colusión.

Las ceremonias son actividades muy controladas. Todo lo que se hace debe estar escrito en un guión, desde el ingreso a la sala hasta el paso a paso de todas las actividades. Este guión está disponible para cualquiera que quiera revisarlo, y existen distintas personas que auditan y certifican que se siguió correctamente. IANA cuenta con certificación de dos auditorías externas anuales.

Por otro lado, las HSM se guardan dentro de bolsas anti-intrusión, y luego dentro de cajas fuertes. Las cajas fuertes están dentro de una jaula con accesos restringidos, y esta jaula está en una oficina especial, en un data center custodiado por guardias armados.

IANA mantiene dos instalaciones de este tipo, cada una con una copia de la información. Uno está en la costa este de Estados Unidos (cerca de Washington DC), y la otra en la costa oeste, en Los Angeles.

3. ¿Cuál es mi labor ahí?

Los TCRs son seleccionados desde distintos lugares del mundo, para representar la comunidad completa. Actualmente somos 4 personas de latinoamérica, que se reparten distintos roles y se dividen en las dos ubicaciones donde se hacen las ceremonias.

Tal como fue indicado en la pregunta anterior, para activar los HSM se necesita de un quórum de tarjetas inteligentes. Estas tarjetas son custodiadas por “Cryptographic Officers” (oficiales criptográficos), y es necesario que de los siete oficiales, al menos tres estén presentes para activarlas.

Es por esto que mi labor como CO sea asistir a las ceremonias, presentar la tarjeta al administrador de la ceremonia, y certificar que las actividades que se realizan sean fieles al guión. Por último, es importante también preocuparse de que los HSM sean desactivados luego de su uso, almacenados correctamente en sus bolsas y cajas fuertes, y custodiar la tarjeta que le corresponde hasta la siguiente ceremonia.

4. ¿Dónde puedo aprender más?

IANA maneja un sitio donde está públicamente todas las políticas, procedimientos y guiones que controlan las ceremonias de firma de la raíz: IANA DNSSEC Information.

También se encuentra el material de cada ceremonia, incluyendo el guión con las notas escritas, ¡y un video de toda la actividad! Este video se transmite en tiempo real y cualquiera puede seguirlo, e incluso hay un experto presente revisando sus comentarios, así que pueden aprovechar de consultar ahí mismo sus dudas.

5. Todo esto parece de una película, ¿no?

Por supuesto se armó bastante revuelo con lo de “las siete llaves que controlan Internet” :) Hay bastantes notas de prensa y artículos, algunos más acertados que otros.

Y en realidad ya ha aparecido en algunos capítulos de series ;)

Acá tenemos una escena de la serie “The Blacklist Redemption” del año 2017, y otra de “Elementary” (solo en inglés).

También hubo la visita de un Youtuber famoso, quien hizo un par de notas.

Y en un lado más serio, la BBC hizo un documental, del cual solo he conseguido los primeros segundos.

Today I was asked for a way of reversing an IPv6 address. We all know that, unlike IPv4, the IPv6 addresses are hard to reverse, because you need to dot-separate each “nibble” (4 bits, an hexadecimal single character), obtaining a domain name of 34 levels depth! (32 plus 2 of the ip6.arpa suffix).

I always use dig for this, but I also tried two more, just for research purposes!

Surely there’re scripts and tools that make it a simple command, but using what I have in hand, how hard could it be using my IDE of choice, vi?

That’s 45 seconds of work! (and to be fair, is vi with some linux base commands)

Next I used a library in perl, Net::IP:

$ perl -MNet::IP -E '$i=new Net::IP("2800:3f0:4003:c03::6a"); say $i->reverse_ip;'

A surprising 24 seconds mark!

And finally, my tool of choice: sending a dig query with -x. It doesn’t matter the answer, just the “question section” line:

And of course dig is the undisputed winner, with 4 seconds ;)

UPDATE: of course it had to be a better tool and didn’t know! Thanks to JPMens on Mastodon now I know of “arpaname”, which just accepts a number and gives the reverse almost instantaneously (I didn’t like the uppercasing though, so had to pipe it to awk '{print tolower($0)}' to have an equivalent output).

When deciding to sign a zone with DNSSEC, one of the initial decisions is which “deny” system to use. There are currently two, the original and simpler called “NSEC”, and a later one that is much more complex, called “NSEC3”. (Why is there no “NSEC2”? For the same reason that there is no IPv5).

The recommendation has always been to use NSEC3 only in special cases, generally oriented to registries (TLD) that require for legal or privacy reasons to keep the list of subdomains secret. NSEC3 is also attractive for this type of records because it allows you to partially sign your zone, using the opt-out technique, which allows you to gradually grow in zone and record size, as subdomains activate DNSSEC, sacrificing a little security.

But hey, each administrator has the reasons and decides which technique he will use.

If you decide to use NSEC3, you must immediately define other important variables, such as signing algorithm, key size, etc; and among some of those decisions is to define two parameters that have to do with the “salting” of the names: number of iterations and size of the salt, as well as the regular change of this last value.

This is cryptographic information that allows greater security to avoid the discovery of the names of a zone. In general, signing software comes with reasonable default values, and in a large number of installations these values are not modified.

However, a concern has recently begun to put limits on these two values. Security analysis by cryptographic experts have considered that it is not necessary to have these salt parameters or iterations in most zones, so the current recommendation is: zero the iterations, and use an empty salt. It is considered that the security gain of setting higher values is minimal, and it has the disadvantage of demanding high processing from the resolvers that must validate the records in that zone.

Although the current standard has somewhat exaggerated theoretical limits, and nothing prevents the use of large values, the problem is that now the resolvers are who can in turn prohibit higher values by implementation, which can mean high processing and high response times to resolve and validate domain names in these zones. Nothing prevents them from protecting themselves against unreasonable values.

This is how last month (March 2021), we already have the first open source resolver software that has decided to set a maximum limit of 150 iterations for validity with NSEC3 [1] (Update: Bind9 also limits to 150 iterations[4]). If a domain currently indicates more than 150 iterations, that resolver will refuse to validate it, and will mark the zone as “insecure”, that is, just as if it did not have DNSSEC active!

Work is already under way at the standards level in the IETF [2] to write a document that analyzes this situation, and talks [3] on the subject have been held at DNS conferences.

We therefore recommend that you check how many iterations you are doing in your domain, if you are using NSEC3. Any query for the type “NSEC3PARAM” returns this value in the third number, for example this domain “example.cl” has 250 iterations and the salt value “4240ECEF733CBFBD”:

$ dig -t nsec3param example.cl + short 1 0 250 4240ECEF733CBFBD

The recommendation is to lower the value of the number of iterations to 0 (actually this number is the “extra” of iterations, since there is always 1), and leave the salt empty (value “-”). For example, the Bind tool “dnssec-signzone” accepts the parameters “-3 - -H 0” that achieve this result.

References: - [1]: “validator: downgrade NSEC3 records with too many iterations”, Knot Resolver 5.3.1 (2021-03-31), https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1 - [2]: “Guidance for NSEC3 parameter settings”, draft document in IETF, https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/ - [3]: “NSEC3 Iterations etc. High Counts and opt-out considered harmful, avoid fixed salt”, talk from ICANN DNSSEC Workshop, (PDF), https://cdn.filestackcontent.com/content=t:attachment,f:%228.%20Viktor%20Dukhovni%20NSEC3-ICANN.pdf%22/m2OglWwSR2o9L4m6Xsgo - [4]: “DNSSEC responses containing NSEC3 records with iteration counts greater than 150 are now treated as insecure”, Notes for BIND 9.16.16 (2021-05-20)