Resumen

  • Los responsables de DNSOP vieron apoyo claro para adoptar draft-huque-dnsop-multi-alg-rules-08, pero remitieron las dudas sobre complejidad al trabajo posterior del grupo.
  • El borrador crea los estados UNIVERSAL y FORMERLY-UNIVERSAL para decidir cuándo un firmante puede omitir firmas de algoritmos anunciados.
  • El mismo estado condicionaría cómo responde un validador que haya deshabilitado localmente un algoritmo; no es una clasificación meramente informativa.
  • Daniel Kade propone un recibo de evidencia de despliegue para cada cambio futuro de estado, separado del registro que acredita la adopción del borrador.

El resultado contiene una condición

El cierre de la convocatoria no declara vencedor al mecanismo. Los chairs informan de apoyo claro para adoptar el documento y, a continuación, conservan las preocupaciones sobre su complejidad para el trabajo posterior. La segunda frase limita el alcance de la primera.

La convocatoria estuvo abierta del 13 al 31 de agosto. La ficha actual en Datatracker muestra un Internet-Draft activo con estado de Working Group Adopted by a WG. Del lado del IESG solo dice I-D Exists; no figura shepherd, Area Director responsable ni fecha de telechat. La revisión 08 ha entrado en la custodia editorial de DNSOP. No se ha convertido en RFC ni en una regla aprobada por el IETF.

La adopción permite cambiar el texto precisamente porque las objeciones siguen vivas. Tratarla como aprobación del diseño quitaría al grupo el margen que el propio cierre acaba de preservar.

La obligación vigente resuelve una incertidumbre costosa

RFC 4035 exige que cada RRset tenga una firma producida con al menos una clave de cada algoritmo presente en el DNSKEY del ápice, y que ese DNSKEY se firme con cada algoritmo anunciado por el DS del padre. RFC 6840 vuelve a formular la obligación del firmante y aclara que los validadores deben aceptar cualquier ruta válida.

La carga cae en quien firma porque no puede saber qué subconjunto de algoritmos entiende cada validador. Publicar todas las firmas evita que la ausencia de una compatible parezca un ataque de degradación. Pero también impone un acoplamiento: RFC 8901 necesita que los proveedores de un esquema multifirmante compartan al menos un algoritmo. Si sus catálogos son disjuntos, el traspaso de una zona no encaja en el modelo actual.

La revisión 08 quiere abrir esa puerta. Enumera servicios con varios firmantes, migraciones entre proveedores, cambios separados de KSK y ZSK, prepublicación de anclas de confianza y experimentos con algoritmos nuevos sin sincronizar a todos los proveedores. La decisión de DNSOP reconoce que vale la pena resolver esos casos. Todavía no selecciona la semántica definitiva.

UNIVERSAL sería una instrucción, no un adjetivo

El borrador pide añadir al registro de IANA una columna Validation support status, con valores UNIVERSAL, FORMERLY-UNIVERSAL o vacío. Inicialmente daría el primer estado a los algoritmos 8 y 13. El registro de algoritmos DNSSEC de IANA no contiene hoy esa columna. Sí identifica 8 y 13 como MUST para implementación de validación.

Cuando el conjunto de DS o anclas anuncie al menos un algoritmo UNIVERSAL y ninguno FORMERLY-UNIVERSAL, el firmante podría servir solo una firma universal. Las firmas de los demás algoritmos anunciados serían opcionales. En las demás combinaciones seguiría haciendo falta el conjunto completo.

Para el validador, la propuesta cambia la clasificación del resultado. Si no soporta un algoritmo anunciado que sea UNIVERSAL o que lo haya sido, debe tratar la zona como no firmada incluso cuando soporte otro algoritmo del conjunto. En caso contrario acepta cualquier ruta válida. Un validador que deshabilita un algoritmo por política local tendría que recordar su historia de clasificación.

Por eso la nueva columna produciría comportamiento en el paquete y en el código. Define lo que puede faltar y cuándo una incompatibilidad local termina como Insecure en vez de Bogus. Si el estado llega demasiado pronto o queda obsoleto, el error también se distribuye.

RFC 9904 ofrece un precedente útil, pero no una aprobación anticipada. Trasladó a IANA las recomendaciones canónicas de uso e implementación y distinguió lo que un producto debe implementar de lo que un operador debería usar. La taxonomía nueva tendría otro propósito y consecuencias adicionales; necesita su propio fundamento.

El apoyo al trabajo convivió con el rechazo del mecanismo

El hilo público explica la cautela de los chairs. Mark Andrews se opuso y cuestionó la premisa sobre soporte global. Paul Hoffman aceptó la necesidad de relajar la regla vigente, pero rechazó la forma actual de UNIVERSAL y FORMERLY-UNIVERSAL. Paul Wouters apoyó la adopción y pidió una simplificación profunda.

Son opiniones individuales, no una votación que este artículo pueda volver a contar. Sirven para ubicar el desacuerdo que el cierre institucional mantiene abierto. DNSOP obtuvo autoridad de cambio sobre un texto discutido, no una razón para borrar la discusión.

El propio borrador dice que el protocolo no puede determinar el soporte universal. Corresponde a la comunidad promover un algoritmo solo cuando considere insignificante la población de validadores que no lo admite. Ahí aparece la pregunta de gobierno: ¿qué población se observó, en qué fecha y con qué umbral?

Separar el recibo empírico del recibo de adopción

Cada futura Standards Action sobre la clasificación debería publicar una ficha verificable. Incluiría algoritmo, versión exacta del registro, fecha de medición, conjunto de validadores observado, exclusiones conocidas, implementaciones antiguas y criterio empleado para considerar insignificante el no soporte.

También debería modelar resultados Secure, Insecure y Bogus durante traspasos y configuraciones multifirmante; documentar preferencias locales; nombrar dependencias de firmantes y proveedores; fijar una ventana efectiva y asignar a alguien la reversión de emergencia. Es posible proteger identidades y datos de flotas. No es legítimo ocultar la base de una afirmación global.

La especificación común mínima de Heng Lu ayuda a fijar el límite. Solo debe centralizarse el hecho de interoperabilidad que todos necesitan compartir. Elegir entre algoritmos admisibles sigue siendo una decisión local, salvo que un proceso normativo posterior demuestre por qué esa libertad debe restringirse.

La adopción ya tiene un recibo claro: problema aceptado, complejidad pendiente. Si la taxonomía llega al registro, necesitará otro recibo, con evidencia y autoridad propias. Confundirlos haría que un estado de edición decidiera prematuramente un estado de la red.

Fuentes