[lac-discuss-en] Fwd: [At-Large] SAC133: SSAC Comments on Proposed Root KSK Algorithm Rollover
[[-- 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 . . . . . . . . . . . . . . . .
Querido Alejandro, coincido que estos tipos de debate profundo sobre temas que tienen vinculación directa con ICANN y por consiguiente con LACRALO, deberíamos darlo por este medio, el cual es idóneo para alcanzar en el debate a todos los miembros de nuestra región. Hay que tener en cuenta que LACRALO tiene grupos de trabajo (con muchos compañeros nativos de las 2 lenguas dentro de el), uno de ellos es DNSSEC, Oscar Giudice es su Director y debería este grupo organizar un taller de trabajo con especialistas para debatir estos temas. Se me ocurre que quizas eso pueda ser en conjunto con el Grupo de trabajo de Capacitación, quienes también tienen un montón de contactos que pueden poner a disposición para eso, no sería la primera vez en la región que los grupos de trabajo trabajen coordinadamente para traer algunos tipos de debate para que nuestra región pueda tener posiciones informadas a la hora de difundir o participar. Pongo esto en relieve, porque parece que hay una idea de dejar de lado nuestras reglas de procedimiento y principios operativos, hace 7 meses que no hay reunión del Directorio (Título VII - Sobre el Directorio de LACRALO - Principios Operativos- y Título X – Sobre el Directorio de LACRALO en las Reglas de Procedimiento), cuestión que infringe nuestras leyes y no permite que haya un trabajo real y productivo en la región, más allá que textualmente indica que debe de tener una reunión mensual, que no se está realizando. Le he pedido en forma personal y luego en forma semi pública (poniendo a los directores en copia), mi preocupación por esta actitud del presidente y secretaria, como así también poniéndome a disposición para ayudarlos. Los Directores de Políticas de LACRALO fueron elegidos democráticamente por sus compañeros de grupo, están activos como el Grupo de Trabajo de UA, Grupo de Trabajo de Gobernanza, Grupo de Trabajo de Comunicación, Grupo de Trabajo de Capacitación y otros estaban por ser operativos como el tan necesario Grupo de Trabajo de Asuntos Contractuales que nos ayudarian a poner blanco sobre negro las cuestiones legales que discute ICANN y que nosotros debemos dar consejo al Board. La participación, la coordinación y las tomas de decisiones debe de ser amplia, nuestras leyes dan un claro mensaje sobre esto y nos indican donde se toman las definiciones ( en la región), donde se coordina el trabajo regional (en el directorio), etc. Cada estamento incorporado en nuestras Leyes son producto de un gran debate en el Grupo de Trabajo de Gobernanza, con un rico debate de participantes de todas las subregiones de LACRALO, luego de haber pasado por un proceso de mediación regional que muchos de nosotros participamos hace unos años. Nadie puede torcer las reglas porque alguna no le gusta. Algo aprendí en mis años de participación en ICANN, el consenso es una gran herramienta que nos ayuda a poder avanzar en acuerdos consolidados entre todos. Mis dos centavos! Un abrazo a todos! *Sergio Salinas Porto**Presidente Internauta Argentina - LACRALO/ICANN <https://atlarge.icann.org/ralos/lacralo>**Asociación Argentina de Usuarios de Internet <http://www.internauta.org.ar/>/FeTIA <http://www.fetia.org.ar/>**FUILAC- Federación de Usuarios de Internet de LAC <https://fuilac.org>**facebook: salinasporto <http://www.facebook.com/salinasporto> **twitter: sergiosalinas <http://twitter.com/sergiosalinas>**Mobi:+54 9 223 5 215819**"Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra * * conciencia o violan nuestro sentido común" Eduardo Galeano* El dom, 26 abr 2026 a las 23:52, lac-discuss-en--- via lac-discuss-es (< lac-discuss-es@icann.org>) escribió:
[[-- 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.
Coincido plenamente con el aporte de fondo y forma indicado por Sergio, adhiero a sus propuestas y a disposición para colaborar con el equipo de gobernanza. Cristian Casas Cetic El lun, 27 abr 2026 a las 9:07, Sergio Salinas Porto via lac-discuss-es (< lac-discuss-es@icann.org>) escribió:
Querido Alejandro, coincido que estos tipos de debate profundo sobre temas que tienen vinculación directa con ICANN y por consiguiente con LACRALO, deberíamos darlo por este medio, el cual es idóneo para alcanzar en el debate a todos los miembros de nuestra región.
Hay que tener en cuenta que LACRALO tiene grupos de trabajo (con muchos compañeros nativos de las 2 lenguas dentro de el), uno de ellos es DNSSEC, Oscar Giudice es su Director y debería este grupo organizar un taller de trabajo con especialistas para debatir estos temas. Se me ocurre que quizas eso pueda ser en conjunto con el Grupo de trabajo de Capacitación, quienes también tienen un montón de contactos que pueden poner a disposición para eso, no sería la primera vez en la región que los grupos de trabajo trabajen coordinadamente para traer algunos tipos de debate para que nuestra región pueda tener posiciones informadas a la hora de difundir o participar.
Pongo esto en relieve, porque parece que hay una idea de dejar de lado nuestras reglas de procedimiento y principios operativos, hace 7 meses que no hay reunión del Directorio (Título VII - Sobre el Directorio de LACRALO - Principios Operativos- y Título X – Sobre el Directorio de LACRALO en las Reglas de Procedimiento), cuestión que infringe nuestras leyes y no permite que haya un trabajo real y productivo en la región, más allá que textualmente indica que debe de tener una reunión mensual, que no se está realizando. Le he pedido en forma personal y luego en forma semi pública (poniendo a los directores en copia), mi preocupación por esta actitud del presidente y secretaria, como así también poniéndome a disposición para ayudarlos.
Los Directores de Políticas de LACRALO fueron elegidos democráticamente por sus compañeros de grupo, están activos como el Grupo de Trabajo de UA, Grupo de Trabajo de Gobernanza, Grupo de Trabajo de Comunicación, Grupo de Trabajo de Capacitación y otros estaban por ser operativos como el tan necesario Grupo de Trabajo de Asuntos Contractuales que nos ayudarian a poner blanco sobre negro las cuestiones legales que discute ICANN y que nosotros debemos dar consejo al Board. La participación, la coordinación y las tomas de decisiones debe de ser amplia, nuestras leyes dan un claro mensaje sobre esto y nos indican donde se toman las definiciones ( en la región), donde se coordina el trabajo regional (en el directorio), etc.
Cada estamento incorporado en nuestras Leyes son producto de un gran debate en el Grupo de Trabajo de Gobernanza, con un rico debate de participantes de todas las subregiones de LACRALO, luego de haber pasado por un proceso de mediación regional que muchos de nosotros participamos hace unos años. Nadie puede torcer las reglas porque alguna no le gusta. Algo aprendí en mis años de participación en ICANN, el consenso es una gran herramienta que nos ayuda a poder avanzar en acuerdos consolidados entre todos.
Mis dos centavos! Un abrazo a todos!
*Sergio Salinas Porto**Presidente Internauta Argentina - LACRALO/ICANN <https://atlarge.icann.org/ralos/lacralo>**Asociación Argentina de Usuarios de Internet <http://www.internauta.org.ar/>/FeTIA <http://www.fetia.org.ar/>**FUILAC- Federación de Usuarios de Internet de LAC <https://fuilac.org>**facebook: salinasporto <http://www.facebook.com/salinasporto> **twitter: sergiosalinas <http://twitter.com/sergiosalinas>**Mobi:+54 9 223 5 215819**"Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra *
* conciencia o violan nuestro sentido común" Eduardo Galeano*
El dom, 26 abr 2026 a las 23:52, lac-discuss-en--- via lac-discuss-es (< lac-discuss-es@icann.org>) escribió:
[[-- 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.
_______________________________________________ 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.
Estimado Sergio, estimados colegas. Espero que se encuentren bien. Quisiera comentarles que sumo a lo expresado en el email de Sergio y quisiera colaborar también en los temas relacionados a DNSSEC. Les envío un cordial saludo. Adrian Carballo El lun, 27 abr 2026 a las 9:07, Sergio Salinas Porto via lac-discuss-es (< lac-discuss-es@icann.org>) escribió:
Querido Alejandro, coincido que estos tipos de debate profundo sobre temas que tienen vinculación directa con ICANN y por consiguiente con LACRALO, deberíamos darlo por este medio, el cual es idóneo para alcanzar en el debate a todos los miembros de nuestra región.
Hay que tener en cuenta que LACRALO tiene grupos de trabajo (con muchos compañeros nativos de las 2 lenguas dentro de el), uno de ellos es DNSSEC, Oscar Giudice es su Director y debería este grupo organizar un taller de trabajo con especialistas para debatir estos temas. Se me ocurre que quizas eso pueda ser en conjunto con el Grupo de trabajo de Capacitación, quienes también tienen un montón de contactos que pueden poner a disposición para eso, no sería la primera vez en la región que los grupos de trabajo trabajen coordinadamente para traer algunos tipos de debate para que nuestra región pueda tener posiciones informadas a la hora de difundir o participar.
Pongo esto en relieve, porque parece que hay una idea de dejar de lado nuestras reglas de procedimiento y principios operativos, hace 7 meses que no hay reunión del Directorio (Título VII - Sobre el Directorio de LACRALO - Principios Operativos- y Título X – Sobre el Directorio de LACRALO en las Reglas de Procedimiento), cuestión que infringe nuestras leyes y no permite que haya un trabajo real y productivo en la región, más allá que textualmente indica que debe de tener una reunión mensual, que no se está realizando. Le he pedido en forma personal y luego en forma semi pública (poniendo a los directores en copia), mi preocupación por esta actitud del presidente y secretaria, como así también poniéndome a disposición para ayudarlos.
Los Directores de Políticas de LACRALO fueron elegidos democráticamente por sus compañeros de grupo, están activos como el Grupo de Trabajo de UA, Grupo de Trabajo de Gobernanza, Grupo de Trabajo de Comunicación, Grupo de Trabajo de Capacitación y otros estaban por ser operativos como el tan necesario Grupo de Trabajo de Asuntos Contractuales que nos ayudarian a poner blanco sobre negro las cuestiones legales que discute ICANN y que nosotros debemos dar consejo al Board. La participación, la coordinación y las tomas de decisiones debe de ser amplia, nuestras leyes dan un claro mensaje sobre esto y nos indican donde se toman las definiciones ( en la región), donde se coordina el trabajo regional (en el directorio), etc.
Cada estamento incorporado en nuestras Leyes son producto de un gran debate en el Grupo de Trabajo de Gobernanza, con un rico debate de participantes de todas las subregiones de LACRALO, luego de haber pasado por un proceso de mediación regional que muchos de nosotros participamos hace unos años. Nadie puede torcer las reglas porque alguna no le gusta. Algo aprendí en mis años de participación en ICANN, el consenso es una gran herramienta que nos ayuda a poder avanzar en acuerdos consolidados entre todos.
Mis dos centavos! Un abrazo a todos!
*Sergio Salinas Porto**Presidente Internauta Argentina - LACRALO/ICANN <https://atlarge.icann.org/ralos/lacralo>**Asociación Argentina de Usuarios de Internet <http://www.internauta.org.ar/>/FeTIA <http://www.fetia.org.ar/>**FUILAC- Federación de Usuarios de Internet de LAC <https://fuilac.org>**facebook: salinasporto <http://www.facebook.com/salinasporto> **twitter: sergiosalinas <http://twitter.com/sergiosalinas>**Mobi:+54 9 223 5 215819**"Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra *
* conciencia o violan nuestro sentido común" Eduardo Galeano*
El dom, 26 abr 2026 a las 23:52, lac-discuss-en--- via lac-discuss-es (< lac-discuss-es@icann.org>) escribió:
[[-- 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.
_______________________________________________ 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.
Hola Alejandro Yo me preguntaría ¿por qué motivo se discuten cosas como las que mencionas en un grupo de wapp? ¿será el síntoma de una enfermedad? Posiblemente. Creo que es consecuencia del silencio reinante desde el comienzo de esta última gestión en la dirección de LACRALO. Cuando me sume a ICANN y a la comunidad de LACRALO, era imposible seguir los mail, había movimiento, había vida, ahora solo escucho el silencio de los los cementerios. Entre otros grupos, el de DNS Abuse sigue activo y con actividades programadas para este año, ahora proximamente en mayo en Venezuela gracias a la gestión de Jorge Gonzalez, esperamos que otros colegas de esta comunidad genereren la oportunidad de realizar nuevas actividades en sus ALS o ámbitos de trabajo así como lo hace Alfredo en Colombia. Un tema planteado como el que se menciona en el SAC133 no es algo para tomar a la ligera, se llega a esto luego de discusiones de meses, muchos meses de intercambio de especialistas, no es un asunto para decir a mi me parece que o yo opino que. Pero en la otra mano yo digo, yo opino que: SIN REUNIONES DE DIRECTORIO lo único que conseguimos es silencio y desinformación. Por otro lado la falta del ejercicio democratico esta llevando a que ni siquiera seamos capaces de armar una cita de calendario para Google Calendar. Quedo atento a cualquier comentario Saludos cordiales Oscar Giudice El dom, 26 abr 2026 a las 23:52, lac-discuss-en--- via lac-discuss-es (< lac-discuss-es@icann.org>) escribió:
[[-- 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.
-- *Oscar*
participants (5)
-
Adrian Carballo -
Cristian Casas -
lac-discuss-en＠icann.org -
Oscar Giudice -
Sergio Salinas Porto