[[-- Translated text (en -> es) --]]

Hola a todos,

 En los últimos días ha habido cierta discusión en el chat de WhatsApp.
 de LACRALO sobre DNSSEC y su implementación en ccTLD. Desafortunadamente que
 La conversación permanece fuera de registro, no es multilingüe y no es
 Igualmente accesible para todos los representantes de las organizaciones miembros. La clave
 La conclusión de esa conversación es que intervenir en los administradores de ccTLD es una
 importa tanto o mucho más para la comunidad local que el ccNSO o cualquier otra cosa.
 otra parte de ICANN excluyendo el SSAC. Por favor, Oscar, Laura, Vanda, etc., traigan
 Devuélvalo aquí para que todos puedan participar. Lo siguiente es
 Relacionados, aunque a un nivel diferente:

 Adjunto aquí un mensaje de Matthias Hudobnik a las listas de ALAC.
 respecto al proceso criptográfico clave (¡literalmente!) que protege el DNS,
 el KSK. Como verás fácilmente, hay algunos aspectos técnicos bastante complicados y
 Cuestiones operativas en juego. En particular, es necesario tomar una decisión.
 compromiso entre la fuerza de la protección a la raíz (a través del tamaño)
 de la clave) con la capacidad y el rendimiento de los sistemas que la utilizan, en
 al menos durante un período de tiempo de 2 a 4 años. También hay consideraciones
 de la criptografía postcuántica, pero pueden mitigarse en cierta medida.

 Por favor, consulte con los miembros con conocimientos técnicos de su ALS y, en la medida de lo posible,
 en la medida de lo posible, con los ISP y los administradores de ccTLD con los que todos deberíamos estar
 en contacto para la realización de nuestros roles, y si es necesario y
 iniciar una discusión apropiada para emitir una recomendación como
 Seguimiento del proceso en curso.

 A nuestros representantes, por favor preparen una presentación con un enfoque adecuado.
 orador si el asunto excede su campo de trabajo, para que la comunidad pueda ser
 mantenerse al tanto de este importante desarrollo y luego poder responder
 preguntas sobre la seguridad y estabilidad del DNS que pueden surgir de
 fuentes inesperadas.

 Tuyo,

 Alejandro Pisanty

 ---------- Mensaje reenviado ---------
 De: Matthias M. Hudobnik vía At-Large<at-large@icann.org>
 Fecha: Viernes, 24 de abril de 2026 a las 14:15
 Asunto: [En general] SAC133: Comentarios del SSAC sobre el algoritmo KSK raíz propuesto
 Dese la vuelta
 A:<at-large@atlarge-lists.icann.org>


 Estimados colegas,

 El SSAC ha publicado el SAC133, que proporciona comentarios sobre la propuesta.
 Transición de Root KSK de RSA/SHA-256 (Algoritmo 8) a ECDSA
 P-256/SHA-256 (Algoritmo 13). Aquí se presenta un resumen de los puntos clave.

 *Soporte general*
 El SSAC respalda la transición del algoritmo propuesta, incluyendo la
 la selección del Algoritmo 13, la metodología de rollover de doble firma y la
 inclusión de SKR de retroceso y programación de fases flexible. Encuentra la
 propuesta coherente con el estudio de cambio de algoritmo de zona radicular de 2024 y
 avisos SSAC anteriores (SAC063, SAC073, SAC102, SAC108), y señala que
 aborda la Recomendación 23 de SSR2. El SSAC anima a ICANN a seguir adelante.

 *Reducción del tamaño de RSA ZSK (2048 → 1536 bits)*
 El SSAC considera que la reducción del tamaño del ZSK es operativamente aconsejable para mantener
 Respuestas de la zona raíz por debajo del umbral del búfer UDP de 1232 bytes (establecido
 por DNS Flag Day 2020) durante la doble firma. Reconoce la reducción
 reduce la seguridad de aproximadamente 112 bits a aproximadamente 96 bits, pero
 Considera esto aceptable dada la corta ventana de exposición pública de cada ZSK.
 (aproximadamente 110 días, o aproximadamente 193 días en el caso de un atacante encubierto)
 escenario). Sin embargo, el SSAC recomienda que el plan de implementación final:

 - Documentar formalmente esto como una excepción estrictamente limitada en el tiempo a
 mejores prácticas criptográficas que no establecen precedentes para el futuro
 operaciones.
 - Incluir una estimación criptográfica del costo computacional y el tiempo
 necesario para descifrar una clave de 1536 bits dentro de su ventana operativa.

 El SSAC también coincide con el rechazo de la propuesta a la alternativa.
 enfoque (pasar el ZSK al Algoritmo 13 antes del KSK), como sería
 violan las reglas obligatorias del algoritmo RFC 6840 y el borrador correspondiente
 La especificación no ha sido adoptada por el grupo de trabajo DNSOP de la IETF.

 *Problemas con los plazos*
 La prórroga propuesta abarca aproximadamente 4 años (Q2/2027 Fase AA hasta
 Q3/2030 Fase HH). El SSAC cuestiona si esta duración es necesaria.
 y plantea dos preocupaciones específicas:

 EE (doble firma / actualización del ancla de confianza a través de RFC 5011) está previsto para
 aproximadamente 2 años, sin embargo, el período de retención obligatorio de RFC 5011 es de solo 30
 días. El SSAC solicita una justificación operativa explícita para esto
 duración y sugiere evaluar un enfoque basado en umbrales utilizando telemetría
 de los aplazamientos de 2018 y 2025 en curso, lo que podría permitir una Fase más corta
 EE si el ecosistema está listo, preservando al mismo tiempo la capacidad de extenderse si es necesario.
 no lo es.

 AA (Generación de KSK ECDSA y almacenamiento seguro, sin cambios en la zona raíz)
 Los objetivos son el segundo trimestre de 2027, aproximadamente seis meses después del KSK de octubre de 2026.
 prórroga. El SSAC cuestiona por qué el cuarto trimestre de 2026 no podría servir como fecha de inicio,
 dado que el personal, las instalaciones y los procedimientos requeridos tendrán
 Acabo de hacer ejercicio.

 Un plazo general más corto también reduciría el tiempo total de 1536 bits.
 El RSA ZSK sigue en uso activo. El SSAC señala además que, si bien
 DNSSEC no se enfrenta a la misma urgencia post-cuántica que otros protocolos.
 ya están implementando PQC, evitando el uso prolongado de un RSA ZSK de potencia reducida.
 reflejaría una buena planificación.

 *Faltan criterios de éxito*
 El SSAC señala que, si bien el plan incluye una programación de fases flexible,
 carece de criterios de éxito definidos o umbrales específicos para cada fase que
 determinaría cuándo es necesaria una extensión del cronograma o cuándo es seguro.
 reanudar. Sin esto, no hay una base objetiva para la transición de fase.
 decisiones.

 *Preparación operativa*
 El SSAC considera que el ecosistema está bien preparado para la transición:

 - El algoritmo 13 es un algoritmo de implementación obligatorio según la RFC 8624.
 y RFC 9904.
 - El despliegue del algoritmo 13 superó al del algoritmo 8 a nivel mundial a partir de abril.
 2024 y continúa creciendo.
 - El algoritmo 13 es implementado por los principales TLD (.com, .net, .gov) sin
 Problemas reportados.
 - La finalización del cambio de algoritmo de SIDN para .nl en 2023 confirmó una amplia
 Soporte de resolución.
 - Todos los principales resolvedores de código abierto (BIND, Unbound, Knot Resolver,
 PowerDNS Recursor) y las plataformas DNS comerciales admiten el Algoritmo 13.
 - Se ha confirmado que los HSM Thales Luna G7 de ICANN están listos para ECDSA dentro de
 Declaración de prácticas de DNSSEC.
 - RFC 5011 sigue siendo el mecanismo principal para el anclaje de confianza del resolvedor.
 actualizaciones.

 *Convenciones Operativas*
 El uso de identificadores de fase distintos (AA a HH) para diferenciar esto
 El reinicio del algoritmo a partir de reinicios previos que no son del algoritmo se anota como un
 Convención sensata.

 Enlace:
 https://itp.cdn.icann.org/en/files/publications/sac-133-10-04-2026-en.pdf.

 Mejor,

 Matías
________________________________

At-Large mailing list -- at-large@icann.org
To unsubscribe send an email to at-large-leave@icann.org

At-Large Official Site: http://atlarge.icann.org
_______________________________________________
By submitting your personal data, you consent to the processing of your
personal data for purposes of subscribing to this mailing list accordance
with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
the website Terms of Service (https://www.icann.org/privacy/tos). You can
visit the Mailman link above to change your membership status or
configuration, including unsubscribing, setting digest-style delivery or
disabling delivery altogether (e.g., for a vacation), and so on.


--
- - - - - - - - - - - - - - - - - - - - - - - - - - -
     Dr. Alejandro Pisanty
Facultad de Química UNAM
Av. Universidad 3000, 04510 Mexico DF Mexico
+525541444475
Blog: http://pisanty.blogspot.com
LinkedIn: http://www.linkedin.com/in/pisanty
Unete al grupo UNAM en LinkedIn,
http://www.linkedin.com/e/gis/22285/4A106C0C8614
Twitter: http://twitter.com/apisanty
---->> Unete a ISOC Mexico, http://www.isoc.org
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
_______________________________________________
lac-discuss-es mailing list -- lac-discuss-es@icann.org
To unsubscribe send an email to lac-discuss-es-leave@icann.org

http://www.lacralo.org
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.