<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[Hugo's Blog]]></title>
  <link href="http://hugo.salga.do//atom.xml" rel="self" />
  <link href="http://hugo.salga.do/" />
  <updated>2026-05-07T09:40:02+02:00</updated>
  <id>http://hugo.salga.do/</id>
  <author>
    <name><![CDATA[Hugo Salgado]]></name>
    <email><![CDATA[hsalgado@vulcano.cl]]></email>
  </author>
  <generator uri="https://github.com/jmacdotorg/plerd">Plerd</generator>


  <entry>
    <title type="html"><![CDATA[Ceremonia 61 de firma de la raíz del DNS]]></title>
    <link href="http://hugo.salga.do/2026-05-07-ceremonia-61-de-firma-de-la-ra%C3%ADz-del-dns.html"/>
    <published>2026-05-07T14:12:00+02:00</published>
    <updated>2026-05-07T09:40:01+02:00</updated>
    <id>http://hugo.salga.do/2026-05-07-ceremonia-61-de-firma-de-la-ra%C3%ADz-del-dns.html</id>
    <content type="html"><![CDATA[<p>A fines de abril del 2026, se realizó la ceremonia número 61 de la
<a href="2023-12-13-la-ceremonia-de-firma-de-la-raíz-del-dns.html">firma de la raíz del DNS</a> en la base de la costa este de Estados Unidos. Asistimos
como Operadores Criptográficos Pía Gruvö, Ondřej Filip, Lodrina Cherne
y yo.</p>

<p>Esta ocasión fue un proceso normal de firma de la ZSK que estará
publicada el tercer trimestre de este año, y continuar con
la pre-publicación de la nueva KSK, recordando que al estar en medio
del <a href="2024-05-16-nueva-ksk-para-la-raíz-del-dns-la-ceremonia-53.html">proceso de rotación de KSK</a> se debe tener cuidado de generar distintos
escenarios, considerando casos de emergencia como podría ser el retiro
de la nueva KSK. Esta es la última ceremonia donde se firma con la
KSK actual. Ya la próxima en la costa Oeste verá las primeras firmas
con la nueva KSK y nuevos HSM.</p>

<p>Durante la ceremonia 61 también aprovechamos de destruir dos de los
HSM antiguos. Esta destrucción fue primero lógica, borrando las llaves
antiguas que estaban presentes (las KSK 2010 y 2017), para luego pasar
a una destrucción física con destornilladores, alicates y tijeras
para asegurar que no existía posibilidad de recuperar nada de información.
Los componentes electrónicos críticos serán llevados a una empresa
especializada en eliminación segura de hardware, que reducirá los
circuitos a arena!</p>

<p>Además hubo una pre-ceremonia de mantención que permitió agregar
dos nuevos cubículos a la caja fuerte de material criptográfico,
listos para reemplazar o incorporar a nuevos oficiales.</p>

<p>Ya quedan pocos meses para la rotación de la KSK, recuerde como siempre
verificar que su resolver tiene <a href="https://www.iana.org/dnssec/files">la nueva llave</a> lista para funcionar.</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[Cambio de firmador en DNSSEC]]></title>
    <link href="http://hugo.salga.do/2025-10-28-cambio-de-firmador-en-dnssec.html"/>
    <published>2025-10-28T16:45:00+01:00</published>
    <updated>2025-10-28T17:00:05+01:00</updated>
    <id>http://hugo.salga.do/2025-10-28-cambio-de-firmador-en-dnssec.html</id>
    <content type="html"><![CDATA[<p>Una de las acciones dentro de DNSSEC que no aparece muy documentada
es cómo puedo <strong>cambiar mi firmador</strong>. Supongamos que llevo años
firmando con una herramienta, usando algún HSM para guardar las llaves,
pero quiero darlo de baja y pasarme a otra herramienta que tiene otro
HSM propio.</p>

<p>Como sabemos, los HSM <strong>por diseño</strong> no permiten sacar las llaves
privadas. Entonces ¿cómo hacemos el traspaso de un sistema de firmado
a otro, sin quebrar DNSSEC?</p>

<p>La respuesta corta es: haciendo un rollover con DS-doble, manteniendo
el mismo algoritmo.</p>

<p>La respuesta larga a continuación.</p>

<p>Requisitos importantes:</p>

<ul>
<li><p>los HSM no permiten exportar las llaves privadas (si lo permitieran,
entonces no existe problema. Se importan en la nueva plataforma y listo).</p></li>
<li><p>debo mantener el mismo algoritmo antes y después (luego, cuando
el cambio ya esté hecho, puedo hacer un rollover de algoritmo en
la nueva plataforma)</p></li>
<li><p>mi sistema de firmado antiguo y nuevo <strong>deben permitir</strong> incorporar
llaves externas en la zona (sólo la parte pública).</p></li>
</ul>

<p>Manos a la obra.</p>

<p>En la situación original, supongamos que tenemos un sistema de firmado
llamado “actual”, con un HSM que tiene 2 llaves: una KSK y una ZSK. Las
partes privadas de las llaves están dentro del HSM, y las públicas están
en el registro DNSKEY de la zona, firmados con la KSK. El DS en el
padre apunta a esta KSK. Una zona firmada completamente norma, hasta ahora.</p>

<p>El primer paso es armar nuestra nueva plataforma, que llamaremos
“nueva”. Como esta plataforma tiene su propio HSM, va a tener unas
llaves distintas KSK y ZSK, que voy a crear en este momento. Esta zona
“nueva” no va a estar publicada en el DNS aún, solo en mi laboratorio.
El DS asociado a esta nueva KSK no estará en ninguna parte.</p>

<p>Una vez que he hecho pruebas de la nueva plataforma y todo se ve
bien, comienza la acción.</p>

<p>El segundo paso es incorporar la nueva ZSK pública de la nueva plataforma
dentro del DNSKEY set de la plataforma actual. Cada herramienta tiene su
forma particular de hacerlo. Por ejemplo en Knot se puede hacer “keymgr
import-pub”. En Bind existe “dnssec-importkey”. Lo importante es que a
partir de este paso, el DNSKEY set público será:</p>

<p>`</p>

<pre><code>zona.  DNSKEY  KSK-pública-actual
zona.  DNSKEY  ZSK-pública-actual
zona.  DNSKEY  ZSK-pública-nueva
</code></pre>

<p>`</p>

<p>y todo firmado con la KSK actual.</p>

<p>Esto se deja publicado un tiempo prudente (al menos dos TTL), antes de
pasar al siguiente paso.</p>

<p>El tercer paso es hacer lo mismo en la nueva plataforma: importamos la
ZSK pública <strong>actual</strong> en el DNSKEY set de la zona. Quedará así:</p>

<p>`</p>

<pre><code>zona.  DNSKEY  KSK-pública-nueva
zona.  DNSKEY  ZSK-pública-nueva
zona.  DNSKEY  ZSK-pública-actual
</code></pre>

<p>`</p>

<p>firmado con la KSK nueva. En una zona que no está al aire aún.</p>

<p>Ahora es el momento de mandar el nuevo DS al padre. Dos cosas son muy
importantes: el algoritmo de la nueva KSK es el mismo que el antiguo,
porque así se pueden usar los dos DS indistintamente; y se debe mantener
el DS actual. Es decir, debemos tener <strong>dos</strong> DS en el padre, cada uno
apuntando a cada KSK. La nueva KSK aún no es publicada, pero es importante
tener su DS antes que ocurra.</p>

<p>Acá también esperamos dos TTL por lo menos (TTL del DS en el padre!)</p>

<p>Finalmente llegamos al momento crucial: empezamos a publicar <strong>la nueva zona</strong>,
con nuestras llaves KSK nueva, ZSK nueva, y la ZSK actual (que ahora
pasaremos a llamar “vieja” a esta altura). Como existe un DS nuevo en
el padre apuntando a nuestra nueva KSK, todo va a validar. Y si algún
resolver tenía en su caché un registro antiguo, firmado con la ZSK
antigua, igual va a seguir validando porque la tenemos en nuestro nuevo
DNSKEY set. Todo sigue correcto!</p>

<p>Ahora queda lo último: limpiar todo.</p>

<p>Debemos de nuevo esperar un tiempo, por lo menos un par de TTLs.</p>

<p>Primero sacamos la ZSK antigua del DNSKEY set nuevo, publicamos y esperamos;
y luego podemos pedirle al padre que saque el DS de nuestra KSK vieja,
quedando solo con el DS nuevo.</p>

<p>Volvimos a la situación “normal”, pero en la nueva plataforma!
Felicitaciones. Ha hecho un rollover de KSK con doble-DS, y DNSSEC nunca
se quebró.</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[Ceremonia 57 de firma de la raíz del DNS]]></title>
    <link href="http://hugo.salga.do/2025-05-15-ceremonia-57-de-firma-de-la-ra%C3%ADz-del-dns.html"/>
    <published>2025-05-16T00:12:00+02:00</published>
    <updated>2025-05-16T03:51:48+02:00</updated>
    <id>http://hugo.salga.do/2025-05-15-ceremonia-57-de-firma-de-la-ra%C3%ADz-del-dns.html</id>
    <content type="html"><![CDATA[<p>A fines de abril del 2025, se realizó la ceremonia número 57 de la
<a href="2023-12-13-la-ceremonia-de-firma-de-la-raíz-del-dns.html">firma de la raíz del DNS</a> en la base de la costa este de Estados Unidos. Asistimos
como Operadores Criptográficos Pía Gruvö, Ondřej Filip, Nomsa Mwayenga
y yo.</p>

<p>Esta ocasión fue un proceso normal de firma de la ZSK que estará
publicada el tercer y cuarto trimestre de este año, y continuar con
la pre-publicación de la nueva KSK, recordando que al estar en medio
del <a href="2024-05-16-nueva-ksk-para-la-raíz-del-dns-la-ceremonia-53.html">proceso de rotación de KSK</a> se debe tener cuidado de generar distintos
escenarios, considerando casos de emergencia como podría ser el retiro
de la nueva KSK. Sin embargo se ve todo bien por el momento. Un estudio
realizado por Duane Wessels de Verisign, muestra claramente
que los resolvers han acogido en un 90% la nueva llave luego de
pasado el mes de espera desde que apareció en el keyset de la raíz,
en febrero de 2025
<img src="img/estudioksk.jpg" alt="Gráfico del porcentaje de resolvers que ven cada una de las llaves KSK" id="grficodelporcentajederesolversquevencadaunadelasllavesksk" />
(imagen tomada del estudio <a href="https://blog.verisign.com/security/2024-2026-root-zone-ksk-rollover-initial-observations/">The 2024-2026 Root Zone KSK Rollover: Initial Observations and Early Trends</a>
)</p>

<p>Durante la ceremonia 57 se aprovechó de utilizar una nueva versión del
sistema operativo y herramientas de control de los HSM, llamado coen v2.0.1.</p>

<p>De nuevo fue una ceremonia impecable. Desde que soy CO hace dos años,
¡es la primera ceremonia sin ninguna excepción al guión!</p>

<p>En el keyset de la raíz del DNS debiéramos dos KSK (la actual 20326
y la nueva 38696), la ZSK 53148 y su futuro reemplazo 46441 que aparecerá
a fines de junio; todo firmado por la actual KSK 20326.</p>

<p>Quería aprovechar a oportunidad de contarles que durante la última
conferencia LACNIC43 realizada en Sao Paulo, Brasil; di una presentación
durante el Foro Técnico sobre la rotación de la llave de la KSK, enfocado
hacia los operadores de ISP y empresas que operan DNS resolvers, para
que estén atentos al momento definitivo en octubre de 2026, y revisen
sus sistemas para verificar que ya poseen la nueva KSK (tanto por
una rotación automática vía RFC5011, como por actualizaciones de
sus sistemas operativos o software de DNS). Aproveché de presentar
una herramienta (en estado Beta) que permite revisar si su proveedor
de DNS ya está preparado, usando la técnica de sentinel del RFC8509,
disponible en <a href="https://test.kskroll.vulcano.cl/">https://test.kskroll.vulcano.cl/</a></p>

<p>Pueden ver el video de la presentación en el canal de LACNIC
<a href="https://www.youtube.com/watch?v=rGi2yaRqEkg">en español</a> y con traducción simultánea
<a href="https://www.youtube.com/watch?v=bh3G_TRH8fE">al inglés</a> <a href="https://www.youtube.com/watch?v=r9R3VBCxQ8c">y portugués</a>. Los <a href="img/rotacion-2026-ksk-dns-hsalgado-v2.pdf">slides están acá (PDF 820KB)</a>.</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[57th DNS Root Signing Ceremony]]></title>
    <link href="http://hugo.salga.do/2025-05-15-57th-dns-root-signing-ceremony.html"/>
    <published>2025-05-16T00:12:00+02:00</published>
    <updated>2025-05-16T04:04:51+02:00</updated>
    <id>http://hugo.salga.do/2025-05-15-57th-dns-root-signing-ceremony.html</id>
    <content type="html"><![CDATA[<p>In late April 2025, the 57th <a href="2024-06-08-the-dns-root-signing-ceremony.html">DNS root signing ceremony</a> took place at the US East Coast facility. Pia Gruvö, Ondřej Filip, Nomsa Mwayenga, and I attended as Cryptographic Officers.</p>

<p>This occasion was a standard ZSK signing process. The signed ZSK will be published in the third and fourth quarters of this year. We also continued the pre-publication of the new KSK. It’s important to remember that since we are in the middle of the KSK rollover process, we need to be careful to consider various scenarios, including emergency cases like the potential withdrawal of the new KSK. However, everything looks good for now. A study conducted by Duane Wessels of Verisign clearly shows that 90% of resolvers have adopted the new key after the one-month waiting period since it appeared in the root keyset in February 2025.</p>

<p><img src="img/estudioksk.jpg" alt="Graph of the percentage of resolvers seeing each KSK" id="graphofthepercentageofresolversseeingeachksk" />
(image taken from the study <a href="https://blog.verisign.com/security/2024-2026-root-zone-ksk-rollover-initial-observations/">The 2024-2026 Root Zone KSK Rollover: Initial Observations and Early Trends</a>
)</p>

<p>During ceremony 57, a new version of the operating system and control tools for the HSMs, called coen v2.0.1, was used.</p>

<p>Again, it was an impeccable ceremony. Since I became a CO two years ago, it’s the first ceremony without any exceptions to the script!</p>

<p>In the DNS root keyset, we should have two KSKs (the current 20326 and the new 38696), the ZSK 53148 and its future replacement 46441 which will appear at the end of June; all signed by the current KSK 20326.</p>

<p>I wanted to take the opportunity to tell you that during the last LACNIC43 conference held in Sao Paulo, Brazil; I gave a presentation during the Technical Forum on the KSK key rollover, focused on ISP operators and companies that operate DNS resolvers, so that they are aware of the definitive moment in October 2026, and check their systems to verify that they already have the new KSK (both through automatic rollover via RFC5011, and through updates to their operating systems or DNS software). I took the opportunity to present a tool (in Beta state) that allows checking if your DNS provider is already prepared, using the sentinel technique from RFC8509, available at
<a href="https://test.kskroll.vulcano.cl/">https://test.kskroll.vulcano.cl/</a></p>

<p>You can watch the video of the presentation on the LACNIC channel 
with simultaneous translation into
<a href="https://www.youtube.com/watch?v=bh3G_TRH8fE">English</a>,
<a href="https://www.youtube.com/watch?v=r9R3VBCxQ8c">Portuguese</a>
or the <a href="https://www.youtube.com/watch?v=rGi2yaRqEkg">original in Spanish</a>.
The <a href="img/rotacion-2026-ksk-dns-hsalgado-v2.pdf">slides are here (PDF 820KB, in spanish)</a>.</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[DNS Root Signing Ceremony 55]]></title>
    <link href="http://hugo.salga.do/2024-11-12-dns-root-signing-ceremony-55.html"/>
    <published>2024-11-12T22:12:00+01:00</published>
    <updated>2024-11-26T20:49:49+01:00</updated>
    <id>http://hugo.salga.do/2024-11-12-dns-root-signing-ceremony-55.html</id>
    <content type="html"><![CDATA[<p>In mid-October 2024, a new <a href="2024-06-08-the-dns-root-signing-ceremony.html">root signing ceremony</a> was held, this time with three objectives:</p>

<ul>
<li>the normal one, which is to sign the upcoming ZSKs for the first quarter of 2025;</li>
<li>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.</li>
<li>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.</li>
</ul>

<p>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.</p>

<p>The new KSK-2024 key has the following DS hash and public key:</p>

<pre><code>. 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=
         )
</code></pre>

<p>that you can verify on the <a href="https://www.iana.org/dnssec/files">official IANA site</a> in various formats.</p>

<p>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 (<a href="2024-05-16-nueva-ksk-para-la-raíz-del-dns-la-ceremonia-53.html">remember that starting this year (in spanish only)</a>, 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.</p>

<p>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!</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[Ceremonia 55 de firma de la raíz del DNS]]></title>
    <link href="http://hugo.salga.do/2024-11-11-ceremonia-55-de-firma-de-la-ra%C3%ADz-del-dns.html"/>
    <published>2024-11-11T22:12:00+01:00</published>
    <updated>2024-11-20T22:12:32+01:00</updated>
    <id>http://hugo.salga.do/2024-11-11-ceremonia-55-de-firma-de-la-ra%C3%ADz-del-dns.html</id>
    <content type="html"><![CDATA[<p>A mediados de octubre de 2024 se realizó una nueva <a href="2023-12-13-la-ceremonia-de-firma-de-la-raíz-del-dns.html">ceremonia de firma
de la raíz</a>, esta vez con tres objetivos:</p>

<ul>
<li>el normal, que es firmar las próximas ZSK del primer trimestre de 2025;</li>
<li>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.</li>
<li>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.</li>
</ul>

<p>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.</p>

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

<pre><code>. 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=
         )
</code></pre>

<p>que pueden verificar en el
<a href="https://www.iana.org/dnssec/files">sitio oficial de IANA</a>
en diversos formatos.</p>

<p>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
(<a href="2024-05-16-nueva-ksk-para-la-raíz-del-dns-la-ceremonia-53.html">recuerden que a partir de este año, se comenzó a utilizar dispositivos
Luna</a> 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.</p>

<p>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!</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[New DNSSEC root key released: 38696<br />


]]></title>
    <link href="http://hugo.salga.do/2024-07-25-new-dnssec-root-key-released-38696-.html"/>
    <published>2024-07-25T22:50:00+02:00</published>
    <updated>2024-11-11T23:06:53+01:00</updated>
    <id>http://hugo.salga.do/2024-07-25-new-dnssec-root-key-released-38696-.html</id>
    <content type="html"><![CDATA[<p>As I shared in the last article about the generation of the new
Internet root DNSSEC key, this week it was officially published:</p>

<p><code>
. DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
</code></p>

<p>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.</p>

<p>As always, the official publication site is that of
<a href="https://www.iana.org/dnssec/files">IANA Trust Anchors and Keys</a>.</p>

<p>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.</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[Publicada la nueva llave de la raíz: 38696]]></title>
    <link href="http://hugo.salga.do/2024-07-25-publicada-la-nueva-llave-de-la-ra%C3%ADz-38696.html"/>
    <published>2024-07-25T22:43:00+02:00</published>
    <updated>2024-11-14T00:54:26+01:00</updated>
    <id>http://hugo.salga.do/2024-07-25-publicada-la-nueva-llave-de-la-ra%C3%ADz-38696.html</id>
    <content type="html"><![CDATA[<p>Tal como compartí en el <a href="http://hugo.salga.do/2024-05-16-nueva-ksk-para-la-ra%C3%ADz-del-dns-la-ceremonia-53.html">último artículo acerca de la generación de la nueva llave DNSSEC</a> de la raíz de Internet, esta semana fue publicada oficialmente:</p>

<p><code>
.   DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
</code></p>

<p>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.</p>

<p>Como siempre, el sitio oficial de publicación es el de
<a href="https://www.iana.org/dnssec/files">IANA Trust Anchors and Keys</a></p>

<p>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.</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[The DNS Root Signing Ceremony]]></title>
    <link href="http://hugo.salga.do/2024-06-08-the-dns-root-signing-ceremony.html"/>
    <published>2024-06-08T16:39:00+02:00</published>
    <updated>2024-11-11T23:08:06+01:00</updated>
    <id>http://hugo.salga.do/2024-06-08-the-dns-root-signing-ceremony.html</id>
    <content type="html"><![CDATA[<p>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.</p>

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

<h2 id="whatistherootsignatureabout">1. What is the root signature about?</h2>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h2 id="whataretheceremonies">2. What are the ceremonies?</h2>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h2 id="whatismyjobthere">3. What is my job there?</h2>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h2 id="wherecanilearnmore">4. Where can I learn more?</h2>

<p>IANA maintains a site where all the policies, procedures, and scripts
that control root signing ceremonies are publicly available:
<a href="https://www.iana.org/dnssec">IANA DNSSEC Information</a>.</p>

<p>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.</p>

<h2 id="thisalllookslikesomethingoutofamoviedoesntit">5. This all looks like something out of a movie, doesn’t it?</h2>

<p>Of course there was quite a stir about “the seven keys that control the
Internet” :) There are quite a few 
<a href="https://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwide-internet-security-web">press</a>
<a href="https://www.independent.co.uk/tech/internet-worldwide-web-network-domain-name-system-fourteen-people-seven-secret-keys-hackers-icann-a8129766.html">releases</a>
and
<a href="https://abcnews.go.com/Technology/brotherhood-internet-keys-chosen/story?id=11271450">articles</a>,
some more accurate than others.</p>

<p>And actually it has already appeared in some episodes of series ;)</p>

<p>Here’s a
<a href="https://kumi.tube/w/rw1EC8p8BcS1q75kvuW37x">scene</a> from the
2017 series “The Blacklist Redemption”, and
<a href="https://kumi.tube/w/dwG7ChECwFtcFEz8Usu4WJ">another</a> from
“Elementary”.</p>

<p>There was also a visit from a famous Youtuber, who made
<a href="https://www.youtube.com/watch?v=g4L0kxVIxGY">a couple of notes</a>.</p>

<p>And on a more serious side, the BBC made a documentary, of which I
only got
<a href="https://kumi.tube/w/3UQiC2bWrvYrH65DiJVKoD">the first few seconds</a>.</p>
]]></content>
  </entry>

  <entry>
    <title type="html"><![CDATA[Nueva KSK para la raíz del DNS, la ceremonia 53]]></title>
    <link href="http://hugo.salga.do/2024-05-16-nueva-ksk-para-la-ra%C3%ADz-del-dns-la-ceremonia-53.html"/>
    <published>2024-05-16T23:20:00+02:00</published>
    <updated>2024-11-22T19:42:40+01:00</updated>
    <id>http://hugo.salga.do/2024-05-16-nueva-ksk-para-la-ra%C3%ADz-del-dns-la-ceremonia-53.html</id>
    <content type="html"><![CDATA[<p>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.</p>

<blockquote>
  <p>¿Qué es una ceremonia de firma de la raíz? Revise el <a href="2023-12-13-la-ceremonia-de-firma-de-la-raíz-del-dns.html">artículo anterior con una introducción</a>.</p>
</blockquote>

<p>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.</p>

<p>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).</p>

<p>Como siempre, toda la ceremonia se transmite en vivo por streaming, y
quedan disponibles
<a href="https://www.iana.org/dnssec/ceremonies">los videos y todos los documentos</a>
para su revisión por quien quiera, en el sitio de IANA.</p>

<p>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!</p>

<h2 id="nuevoshsm">Nuevos HSM</h2>

<p>Tal como fuera anunciado
<a href="2023-12-13-la-ceremonia-51-de-la-firma-de-la-raíz-del-dns.html">en el artículo anterior de la ceremonia 51</a>,
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.
<a href="https://www.icann.org/en/system/files/files/hardware-security-module-replacement-2024-28feb24-en.pdf">Acá se encuentra un estudio detallado de comparación de distintos hardware</a>,
y otros caminos posibles que se evaluaron para reemplazar los Keyper.</p>

<p>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 ;)</p>

<p><img src="img/luna.jpg" alt="Imagen de los nuevos HSM Thales Luna, proyectados en una pantalla durante la ceremonia." id="imagendelosnuevoshsmthaleslunaproyectadosenunapantalladurantelaceremonia." /></p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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á.</p>

<h2 id="nuevaksk">Nueva KSK</h2>

<p>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.</p>

<p><img src="img/ksk.jpg" alt="Documento con la descripción de la generación de la nueva KSK, según la salida del HSM." id="documentoconladescripcindelageneracindelanuevaksksegnlasalidadelhsm." /></p>

<p>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
<a href="https://www.iana.org/dnssec/files">sitio oficial de IANA</a>
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.</p>

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

<p>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.</p>
]]></content>
  </entry>


</feed>
