[[-- 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 . . . . . . . . . . . . . . . .