Resumen

  • La finalización del handshake QUIC es local y depende de la perspectiva de cada endpoint.
  • HANDSHAKE_DONE, o el ACK 1-RTT que cumple la condición alternativa en el cliente, confirma un estado de protocolo y permite descartar las claves Handshake.
  • La confirmación debe combinarse con pruebas de 0-RTT y del resultado de la aplicación antes de declarar disponibilidad.

El error operativo suele empezar con una pantalla verde. Llega HANDSHAKE_DONE, el panel marca el servicio como listo y nadie pregunta qué significa exactamente la señal. Sin embargo, el servidor puede haber rechazado los datos tempranos y el cliente puede tener que reiniciar los flujos y el estado de aplicación vinculado a ellos. La señal es válida; la etiqueta de disponibilidad es la que puede ser excesiva.

RFC 9001 sitúa la finalización en el endpoint que observa el estado. El handshake TLS termina cuando la pila TLS local ha enviado un mensaje Finished y ha verificado el Finished del par. No es un acontecimiento simultáneo para ambos extremos. Por eso, un registro serio debe conservar quién observó la transición y con qué evidencia, en lugar de presentar una única marca temporal como si ambos endpoints hubieran llegado al mismo punto a la vez.

La confirmación también depende del papel. En el servidor, el handshake queda confirmado cuando termina y el servidor debe enviar HANDSHAKE_DONE inmediatamente después. En el cliente, la recepción de HANDSHAKE_DONE confirma el handshake. El cliente puede inferirlo alternativamente mediante un ACK que cubra un paquete enviado con claves 1-RTT. RFC 9000 permite que solo el servidor envíe HANDSHAKE_DONE. La trama informa al cliente de que el servidor recibió y procesó su paquete Handshake; no es una respuesta de la aplicación.

La consecuencia principal es una frontera del ciclo de vida criptográfico. Cuando el handshake queda confirmado, el endpoint debe descartar las claves Handshake. Con ello se retira la época criptográfica Handshake. No se demuestra que la negociación de la aplicación haya terminado, que una solicitud haya llegado al código de aplicación, que exista almacenamiento duradero o que un servicio dependiente esté disponible.

Las claves Initial pertenecen a otra transición. El cliente las descarta cuando envía por primera vez un paquete Handshake. El servidor las descarta cuando procesa con éxito por primera vez un paquete Handshake. La evidencia es distinta y el momento no debe confundirse con la confirmación ni con el descarte de las claves Handshake. Un informe que agrupa todo como un solo evento oculta el estado real de la conexión.

La decisión sobre 0-RTT es independiente. El servidor acepta 0-RTT al incluir la extensión early_data en EncryptedExtensions y lo rechaza al omitirla. Si lo rechaza, no debe procesar paquetes 0-RTT y el cliente debe reiniciar todos los flujos, incluido el estado de aplicación ligado a ellos. Un HANDSHAKE_DONE posterior no convierte esos datos rechazados en trabajo aceptado.

Además, la seguridad frente a repetición corresponde al protocolo de aplicación. Los datos de aplicación en 0-RTT pueden procesarse varias veces debido a un replay. El cliente no debe usar 0-RTT para datos de aplicación salvo que la aplicación lo solicite expresamente, y el protocolo debe definir los usos aceptables. La confirmación no prueba seguridad frente a replay, ejecución exactamente una vez, commit duradero ni aceptación de la solicitud temprana.

El ACK 1-RTT tampoco amplía su significado. Si cubre el número de paquete 1-RTT más bajo enviado por el cliente, establece la condición de confirmación prevista por RFC 9001. No demuestra consumo por la aplicación, escritura persistente, autorización ni finalización empresarial. Es un recibo del estado criptográfico, no un recibo de negocio.