Resumen

  • KeyUpdate mueve la clave de envío de un extremo y la clave de recepción correspondiente del otro. La dirección contraria conserva su generación hasta que ejecuta una actualización propia.
  • La eliminación de secretos antiguos puede preservar el tráfico pasado frente a una filtración posterior; conocer el secreto actual, en cambio, permite derivar los futuros. Rotar no equivale a recuperarse de un compromiso.

Dos flechas, no una llave compartida

Hablar de «la clave de una conexión» oculta una parte decisiva de TLS 1.3. El tráfico del cliente al servidor y el del servidor al cliente se protegen con secretos distintos. Cada uno tiene su propia secuencia de generaciones. Esa separación permite que un emisor cambie de clave sin obligar al sentido inverso a cruzar la misma frontera en el mismo momento.

La necesidad aparece en conexiones largas. Los algoritmos AEAD ofrecen garantías acotadas por el volumen de uso de una clave. Cuantos más records protege, más se aproxima el sistema a límites de confidencialidad o integridad que no deberían agotarse. RFC 8446 recomienda actualizar las claves antes de llegar a esos topes, y RFC 9325 pide a las aplicaciones persistentes que consideren su política de renovación.

TLS antiguo tenía la renegociación, una operación capaz de reabrir varias decisiones en una conexión viva. TLS 1.3 la eliminó y delimitó las tareas posteriores al handshake. KeyUpdate no cambia versión, suite, certificado ni identidad. Tampoco reinicia el protocolo que viaja encima. Su mandato termina en las claves de protección de datos de aplicación.

El mensaje cruza con la clave que jubila

El orden evita una frontera ambigua. El emisor cifra KeyUpdate con la clave antigua. Después de ese mensaje, cada record que envía debe usar la clave nueva. El receptor autentica primero la instrucción con su secreto de recepción vigente y luego deriva la generación que necesitará para leer lo siguiente.

Así, la transición queda dentro del historial protegido. No depende de relojes sincronizados ni de una orden lateral. También exige precisión: si una implementación cambia antes de leer el mensaje, pierde la instrucción; si cambia después de tiempo, no podrá abrir el primer record nuevo.

El valor update_not_requested permite que el cambio termine ahí: avanzan el envío de A y la recepción de B. Con update_requested, A pide a B que mande su propio KeyUpdate. Esa respuesta actualiza la otra dirección mediante otro mensaje; no transforma la primera orden en un cambio bilateral instantáneo.

Dos solicitudes pueden cruzarse porque ambos extremos iniciaron la operación de forma independiente. El protocolo obliga a contestar a cada una, pero prohíbe enviar una nueva petición antes de recibir la respuesta pendiente. También rechaza KeyUpdate antes de Finished y exige limitar el trabajo causado por mensajes excesivos. La facultad de mantener claves no es una cuota ilimitada de CPU concedida al par.

Borrar atrás no corta la derivación hacia delante

Cuando una generación vieja deja de ser necesaria para procesar records en tránsito, puede eliminarse. Si más tarde se revela un secreto nuevo, la derivación unidireccional no permite reconstruir automáticamente los anteriores. Esa propiedad reduce el valor de capturas antiguas para quien solo obtiene material de una época posterior.

El beneficio no funciona al revés. Desde el secreto actual se calculan sus sucesores. Un adversario que ya lo conoce puede seguir la misma cadena que los extremos legítimos. Repetir KeyUpdate produce descendientes, no entropía independiente. No autentica de nuevo a nadie ni expulsa por sí mismo al intruso.

Por eso hay que separar el mantenimiento del incidente. Aproximarse al límite de uso AEAD requiere avanzar la generación. Detectar o sospechar que el secreto vigente se filtró requiere cerrar la conexión y realizar un nuevo handshake que aporte material fresco. Un tablero que llama «rotación» a ambas respuestas puede declarar éxito mientras conserva exactamente la cadena comprometida.

HTTP/2 distinguió clave e identidad

La diferencia se vuelve concreta con HTTP/2. Varias solicitudes pueden coexistir en una conexión. Si la identidad autenticada cambia a mitad del recorrido, asignar ese cambio a cada stream resulta inseguro. RFC 9113 prohíbe por ello la autenticación posterior al handshake de TLS 1.3 en HTTP/2.

Sin embargo, permite KeyUpdate: una nueva generación de protección de records no altera por sí misma qué usuario autorizó una petición. El protocolo de aplicación sigue con los mismos streams y significados. La operación encaja porque no reclama la autoridad de la renegociación que TLS 1.3 retiró.

QUIC recuerda que ni siquiera esta mecánica estrecha sirve en cualquier transporte. RFC 9001 veta los mensajes TLS KeyUpdate en QUIC. Como los paquetes pueden llegar desordenados, QUIC usa su bit Key Phase y reglas relacionadas con confirmaciones. Comparte la finalidad de renovar claves, no el mecanismo secuencial de records TLS.

Una transición, no una absolución

El logro de KeyUpdate fue dar a una conexión continua épocas criptográficas explícitas y direccionales. El cambio no modifica la identidad, no restablece la aplicación y no certifica que el entorno sea seguro. Su exactitud es más valiosa que una promesa amplia: limita el uso de una clave y permite retirar el pasado, sin ocultar que el futuro todavía desciende del presente.

Fuentes y límites

Este análisis utiliza RFC 8446, RFC 9001, RFC 9113 y RFC 9325. Los documentos no prueban cuotas de despliegue, valores predeterminados de bibliotecas ni un intervalo universal de renovación.