Resumen

  • RFC 10015 prohíbe que clientes de TLS/DTLS 1.2 ofrezcan y que servidores seleccionen suites con FFDH, FFDHE o intercambio RSA; para ECDH estático establece SHOULD NOT, no MUST NOT.
  • La decisión no retira TLS 1.2 ni todo uso de RSA. Un certificado RSA puede autenticar ECDHE, y FFDHE sigue permitido en TLS/DTLS 1.3.
  • La marca D de IANA no cambia procesos en ejecución. La retirada solo queda demostrada al relacionar configuración efectiva, oferta del cliente, selección del servidor, fallos, excepciones y canarios de aplicación.

El diagnóstico equivocado que empieza por el certificado

Un dispositivo industrial llama a una pasarela una vez por hora. Tras una actualización, la conexión termina antes de enviar datos. El certificado del servidor está vigente, la cadena valida y TLS 1.2 continúa en la política permitida. Cambiar el certificado no arregla nada.

El dispositivo solo ofrece una suite TLS_RSA_*.

Ese dato sitúa el fallo en el límite que define RFC 10015. Desde julio de 2026, el texto de Standards Track exige que, en TLS y DTLS 1.2, un cliente no ofrezca y un servidor no seleccione suites cuyo intercambio de claves sea RSA. El canal puede usar un certificado RSA en otras combinaciones; lo retirado es la construcción donde esa clave también transporta el secreto inicial.

La distinción cambia la respuesta operativa. Reabrir la suite restaura el dispositivo, pero también reabre el camino que la norma pretende eliminar. Mantener el rechazo sin haber identificado al dueño del dispositivo convierte una mejora criptográfica en una interrupción sin responsable. Ninguno de esos extremos prueba una migración bien gobernada.

TLS 1.2 es el contenedor, no el resultado

Una suite de TLS 1.2 reúne autenticación, intercambio de claves, cifrado e integridad. El contador de versión solo informa del contenedor. Dos sesiones “TLS 1.2” pueden tener historias de secreto y exposición muy distintas.

RFC 10015 separa cuatro familias. FFDH usa una clave Diffie-Hellman de campo finito no efímera en el certificado. FFDHE transmite una clave temporal durante el handshake. ECDH y ECDHE hacen una división comparable sobre curvas elípticas.

El mandato para TLS/DTLS 1.2 queda así:

  • FFDH no efímero: el cliente MUST NOT ofrecer y el servidor MUST NOT seleccionar;
  • FFDHE: el mismo MUST NOT en ambos lados;
  • intercambio RSA: el mismo MUST NOT;
  • ECDH no efímero: SHOULD NOT para oferta y selección.

También se desaconseja usar o aceptar los tipos de certificado fijo rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh y ecdsa_fixed_ecdh, aplicables a 1.2 y versiones anteriores.

El diferente verbo normativo evita dos falsificaciones. Una organización no puede registrar ECDH estático como prohibición idéntica a RSA; necesita una justificación fuerte si lo conserva, pero el texto admite circunstancias excepcionales. Tampoco puede dejar RSA o FFDHE al final de la preferencia y declarar cumplimiento: si sigue siendo seleccionable cuando es la única coincidencia, la ruta permanece abierta.

Dos límites que una regla por nombre rompería

“Desactivar RSA” suena claro y puede ser erróneo. Un servidor puede poseer un certificado RSA que firma la autenticación de un intercambio ECDHE. Ese uso no es el intercambio RSA retirado. Bloquear el certificado por el nombre del algoritmo ampliaría el cambio y podría dañar compatibilidad sin reducir el riesgo específico.

“Desactivar DHE” también borra una frontera. RFC 10015 declara que FFDHE en TLS y DTLS 1.3 no padece los problemas expuestos para la construcción 1.2 y puede seguir ofreciéndose. El motor de política debe evaluar versión y suite juntas.

La clasificación exacta requiere observar el handshake. Un inventario de certificados no basta; un inventario de protocolos tampoco. La unidad útil es terminación + configuración cargada + oferta + selección + resultado.

Por qué FFDHE 1.2 dejó de ser una opción de reserva

La clave efímera aporta secreto hacia adelante solo si el resto del mecanismo es sólido. En TLS 1.2, la elección del grupo de campo finito quedó atrapada entre interoperabilidad y verificación. Muchos servidores entregan grupos personalizados; un cliente no puede verificar de forma práctica todas sus propiedades durante la conexión y carece de un mecanismo limpio para pedir otro grupo aceptable.

RFC 7919 estandarizó grupos FFDHE negociados y documentó la presión que llevaba a mantener tamaños ampliamente compatibles. RFC 10015 reúne las razones para terminar el camino 1.2: grupos con subgrupos pequeños, uso persistente de 1024 bits, precomputación reutilizable contra grupos populares y riesgos cuando los secretos supuestamente efímeros se reutilizan, como muestra la familia Raccoon.

No es un juicio abstracto contra Diffie-Hellman. Es una evaluación de un diseño concreto y su historia de despliegue. Por eso el mismo acrónimo tiene un resultado distinto en TLS 1.3.

RSA extiende el incidente hacia atrás y hacia los lados

El intercambio RSA de TLS 1.2 no tiene secreto hacia adelante. Tráfico capturado hoy puede quedar expuesto si la clave privada aparece mañana. Además, las diferencias observables al procesar cifrados RSA mal formados han dado lugar a ataques de oráculo desde Bleichenbacher hasta variantes como ROBOT y DROWN. Implementar la respuesta perfectamente indistinguible sigue siendo difícil.

La expansión lateral procede de la reutilización. TLS 1.2 no ofrece una separación cómoda de dominios para esa clave. Si una pasarela antigua comparte la clave RSA con otros servicios, un oráculo en la pasarela puede alterar la valoración de todo el conjunto. El mapa de huellas de clave privada es, por tanto, parte del plan de retirada.

IANA puede registrar el cambio, no ejecutarlo

RFC 10015 actualiza diecisiete documentos, entre ellos TLS 1.2, DTLS 1.2 y BCP 195. El registro TLS de IANA marca las entradas afectadas con D; RFC 9847 define la señal como desaconsejada para implementaciones o despliegues nuevos.

La fila del registro coordina significado. No cambia una directiva de OpenSSL, la preferencia de un proxy, el firmware de un balanceador ni la política de una región. La publicación tampoco descubre clientes que nadie había censado.

Entre intención y ejecución hay varias autoridades. La biblioteca expone capacidades; la aplicación decide qué habilita; el proxy puede terminar antes que el origen; el cliente decide qué ofrece; el servidor decide qué selecciona; operaciones observa el resultado. Declarar una política en un repositorio no sustituye a ninguna de ellas.

Diseñar la retirada como una prueba reproducible

El inventario empieza por todos los puntos de terminación y origen: servicios públicos e internos, clientes salientes, DTLS, mallas, CDN, dispositivos, appliances y excepciones regionales. Para cada uno se registran dueño, biblioteca y proveedor criptográfico, suites efectivas, límites de versión, SNI/ALPN, certificados, reutilización de clave y población de clientes.

Luego se construye una línea base de negociación. Cada muestra debe enlazar versión, suite, intercambio, terminación y resultado de aplicación. Los fallos se clasifican por primera causa útil: sin suite común, grupo no admitido, certificado, versión o aplicación.

Los canarios cubren afirmaciones positivas y negativas. Una oferta solo RSA o FFDHE en 1.2 debe fallar. Una combinación 1.2 efímera permitida debe funcionar. TLS 1.3 debe seguir disponible y su FFDHE no debe caer por una expresión demasiado amplia. Una oferta mixta debe elegir la ruta prevista.

El despliegue avanza por cohortes con dueño: región, clase de listener, proxy o parque de clientes. Se conserva la huella de configuración anterior y posterior, muestras de handshake, distribución de errores y paquete de rollback. “Configuración aplicada” es un evento; “ruta retirada sin romper las rutas admitidas” es el resultado.

La norma se vuelve real donde corre el código

La primacía del código en ejecución de Heng Lu aporta una prueba incómoda: un RFC no puede generar el transcript de un handshake que nunca observó. La autoridad de la norma se concreta cuando un participante implementa una condición verificable.

Su marco de especificación inicial mínima y decisión futura localizada deja el reparto correcto. La capa común define la incompatibilidad. Cada operador conserva inventario, secuencia, elección de reemplazo, aislamiento, excepción y rollback. La autonomía local no convierte una suite prohibida en compatible; obliga a nombrar el coste y al dueño de cualquier transición.

El RFC fija dónde debe acabar el camino. La organización tiene que demostrar dónde acabó de verdad.