Resumen

  • RFC 9558 define el algoritmo DNSSEC 23 para GOST R 34.10-2012 y el tipo de resumen DS 5 para GOST R 34.11-2012, con un perfil binario exacto.
  • Es una publicación informativa del Independent Submission stream: no expresa consenso del IETF ni acredita la idoneidad criptográfica o el despliegue.
  • La conclusión segura exige recibos distintos para registro, implementación, firma, publicación, DS del padre, capacidad del validador, cadena verificada y uso por la aplicación.

La firma estaba; el camino soportado no

Una organización puede hacer bien cada tarea que controla y aun así no obtener el resultado que cree haber comprado. Publica una DNSKEY de algoritmo 23, firma sus RRsets con GOST R 34.10-2012 y consigue que el padre publique un DS con resumen tipo 5. Su herramienta de laboratorio valida el dominio.

Después aparece un usuario detrás de un resolvedor que no implementa esa suite. El resolvedor descarta los DS que apuntan a algoritmos de clave o resumen desconocidos. Si no queda otro camino soportado, trata la zona como no firmada. No hubo una firma defectuosa. Hubo una diferencia de capacidad.

Esa diferencia es el centro estratégico de RFC 9558. Registrar un identificador permite que dos implementaciones hablen de la misma estructura. No obliga a que el parque instalado la reconozca, ni convierte la publicación en una validación observada.

La clase documental limita la afirmación

RFC 9558 se publicó en abril de 2024 como Informational e Independent Submission. No es Standards Track, no tiene consenso del IETF y el RFC Editor no afirma que sea valioso para implementar o desplegar. El propio texto advierte que las propiedades criptográficas de GOST R 34.10-2012 y GOST R 34.11-2012 no fueron verificadas independientemente en este proceso; ni IETF ni IRTF evaluaron su idoneidad para una aplicación concreta.

Esas frases no son un pie de página diplomático. Definen la autoridad del documento. RFC 9558 coordina un perfil para quienes decidan usarlo. No resuelve la decisión de confianza ni presta el nombre del IETF a una valoración criptográfica ausente.

Por eso el inventario operacional debe conservar la procedencia documental junto al número. «Está en un RFC» no debe aparecer en una aprobación de riesgo sin la mención Independent Submission y las cautelas del texto.

Sesenta y cuatro octetos dejan poco margen

El perfil usa la variante de firma de 256 bits y el juego de parámetros A. El punto elíptico Q=(x,y) se transporta en 64 octetos: primero los 32 de x en little-endian y luego los 32 de y también en little-endian. Tanto la clave pública como la firma miden 512 bits; el resumen mide 256.

Este detalle separa una clave matemática de una DNSKEY interoperable. Un cambio de endianidad no altera la apariencia de una cadena base64 para el ojo humano, pero impide que otro extremo reconstruya el mismo punto. El prefijo ASN.1 de 30 bytes que ofrece RFC 9558 permite alimentar una API X.509 compatible con GOST; no crea un certificado ni una cadena de confianza.

La RRSIG se calcula sobre la entrada canónica de RFC 4034, primero con GOST R 34.11-2012 y luego con GOST R 34.10-2012. El valor k del ejemplo se publica sólo para reproducirlo y no puede reutilizarse en producción. La prueba de que dos programas obtienen el mismo vector no demuestra una generación aleatoria segura.

Un número para la firma y otro para el enlace parental

IANA asigna el 23 a ECC-GOST12 en el registro de algoritmos DNSSEC. En otro registro, asigna el 5 a GOST R 34.11-2012 como algoritmo de resumen DS OPTIONAL. Son identificadores relacionados, no intercambiables.

El 23 describe cómo interpretar DNSKEY y RRSIG. El 5 describe cómo el DS del padre resume la DNSKEY del hijo. La RRSIG puede ser verificable con una clave que el padre nunca enlazó. El DS puede coincidir con una DNSKEY que el resolvedor no sabe usar. El software puede soportar ambos y observar todavía una versión antigua en caché.

Un recibo útil identifica los RRsets exactos, el serial, el punto de observación, el TTL, las ventanas de firma, el ancla, la versión del validador y su lista de algoritmos. Sin esos datos, «DNSSEC correcto» es una conclusión imposible de reproducir.

No soportado no es lo mismo que Bogus

RFC 6840 aclara la semántica que vuelve crítica la compatibilidad. Un validador ignora los DS autenticados que especifican algoritmos de clave o de resumen que no soporta. Si ninguno queda, se comporta como ante una delegación sin DS y trata la zona como no firmada.

Bogus es otra cosa: un camino que debía verificar no supera los controles. Mezclar ambos estados puede generar respuestas operativas opuestas. Un equipo puede investigar una firma rota cuando el problema real es que nunca existió un camino ejecutable en esa versión del software.

El informe de incidente debe responder qué resolvedor tomó la decisión, qué algoritmos tenía habilitados, qué DS y DNSKEY observó, qué ancla usó y qué estado devolvió. Una validación exitosa desde una sola red no cubre a todas las poblaciones.

La firma doble compra tiempo, no simplicidad

RFC 9558 recomienda dos algoritmos KSK mientras el soporte GOST no sea amplio, salvo que el uso exclusivo sea deliberado. La segunda ruta ofrece continuidad a los validadores que no conocen el algoritmo 23.

Pero cada ruta adicional tiene reloj propio. Hay que coordinar claves, DS, RRSIG, vencimientos, publicación del padre y cachés. RFC 6840 favorece aceptar cualquier RRSIG válida y declarar Bogus sólo si fallan todas, pero una política local más restrictiva o estados almacenados en momentos distintos pueden producir resultados diferentes.

La migración necesita criterios observables para añadir y retirar. Una vista con dos claves no prueba que el algoritmo anterior ya sea prescindible. La prueba llega cuando validadores independientes, durante el horizonte de caché relevante, construyen de forma consistente la ruta que permanecerá.

La aplicación todavía debe decidir

Una cadena Secure autentica datos con relación a un ancla configurada. No prueba que el servicio responda, que el dueño jurídico sea quien se supone, que el algoritmo cumpla toda política ni que una conexión posterior tenga éxito.

También hay una frontera entre el validador y el cliente. DO solicita material DNSSEC; CD modifica la comprobación; AD comunica un resultado bajo condiciones. Si el canal al resolvedor no es confiable o la aplicación no consume el estado, el bit no se convierte en evidencia de extremo a extremo.

El último recibo debe registrar el resolvedor elegido, el canal, el estado DNSSEC, la regla de la aplicación, la acción y el efecto observado. RFC 9558 permite formar nuevos objetos. La autoridad para actuar sigue fuera del registro.

Fuentes

Fuentes