Resumen

  • El documento activo es draft-ietf-tls-extended-key-update-13; la revisión 11 ya es histórica y el trabajo sigue siendo un Internet-Draft, no un RFC aprobado ni una capacidad desplegada.
  • Request, response y finish pueden introducir material nuevo y mover las claves de tráfico, pero ninguna de esas señales certifica el borrado de los secretos viejos.
  • La afirmación de recuperación necesita unir negociación, secuencia, generación efímera, derivación, destrucción local, transición por dirección y una prueba de aplicación de ida y vuelta.

La referencia cambió y la cautela permanece

El Datatracker del IETF muestra la revisión 11 como anterior. La revisión 13, del 4 de julio de 2026, vence el 5 de enero de 2027. Aspira a Proposed Standard, pero su estado IESG sigue siendo «I-D Exists» y no tiene director de área responsable ni fecha de telechat.

La revisión 13 renombró el subtipo 2 como key_update_finish, aclaró que los tres mensajes se protegen con las claves antiguas y amplió el análisis del atacante activo. Por eso una declaración de compatibilidad debe identificar la revisión y la conducta observada. Decir «aprobado por IETF» sería incorrecto.

Capacidad, política y sesión son pruebas diferentes

El cliente propone Extended_Key_Update mediante TLS flags en ClientHello. El servidor lo confirma en EncryptedExtensions solo si lo admite y lo tiene habilitado. Si no hay confirmación, una aplicación que necesita seguridad poscompromiso debe hacer un handshake completo.

Después de negociar EKU, el KeyUpdate clásico queda prohibido y provoca unexpected_message. La petición y la respuesta deben usar el grupo acordado en el handshake original; otro grupo provoca illegal_parameter. Que el binario contenga código, que la política lo active y que esta sesión lo haya negociado son tres hechos distintos.

La conexión no cambia de una sola vez

El iniciador envía key_update_request con un key share efímero. El respondedor devuelve key_update_response y cambia primero su clave de envío. El iniciador deriva los secretos, cambia la recepción, envía un key_update_finish vacío protegido aún con la clave anterior y después cambia el envío. El respondedor solo cambia la recepción cuando autentica ese finish antiguo.

Durante el intervalo, cada extremo puede estar en una generación distinta según el sentido. Un campo único de «versión de clave» oculta esa realidad. Si las peticiones se cruzan, pierde el valor key_exchange lexicográficamente menor; si son iguales, la conexión se cierra.

La derivación mezcla el secreto compartido nuevo con un valor ligado al main secret previo y un transcript hash que cubre el handshake y las actualizaciones. De ahí salen ambos secretos de tráfico, el exporter secret y el resumption main secret. A diferencia de KeyUpdate, el estado sucesor deja de depender solo de la cadena comprometida.

El límite entre protocolo y ejecución

Una traza puede mostrar shares nuevos y registros compatibles. No prueba que el generador aleatorio fuera sano, que no hubiera reutilización, ni que desaparecieran copias del heap, HSM, kernel o volcado de fallo. El borrador dice que las implementaciones DEBERÍAN borrar secretos previos cuanto antes; el par remoto no puede atestiguarlo.

La evidencia operativa debe enlazar, sin registrar claves: revisión y grupo negociados, identificador de generación efímera, identificadores de los tres mensajes, generación sucesora, resultado de destrucción de cada almacén y primer registro aceptado con claves nuevas en cada dirección.

Además, el atacante debe haber perdido acceso a ambos extremos. Un intruso persistente lee el estado nuevo; uno activo con las claves actuales puede sustituir mensajes y mantener un MitM salvo que se ejecute la autenticación adicional de la sección 11. Recuperar una conexión tampoco remedia una clave de identidad de largo plazo comprometida.

En DTLS aparecen epochs, retransmisiones, conservación temporal del estado viejo y ACK. El iniciador no completa el cambio de envío hasta recibir el ACK del epoch nuevo. Un panel de TLS no demuestra ese proceso cambiando solo el nombre del protocolo.

Fuentes