Resumen

  • Aceptar QUIC 0-RTT es una decisión de TLS y transporte, no una prueba de ejecución única en la aplicación.
  • Un ACK demuestra procesamiento de transporte, pero no entrega aplicativa, commit durable, identidad autenticada ni éxito comercial.
  • El protocolo de aplicación debe limitar el uso de datos tempranos y conservar evidencias separadas para ejecución, idempotencia y resultado.

QUIC 0-RTT permite que el cliente reutilice configuración de una conexión anterior, incluido un ticket de sesión TLS, para enviar datos de aplicación antes de completar el nuevo handshake. El servidor acepta esos datos mediante la extensión TLS early_data en EncryptedExtensions. Después procesa y acusa recibo de los paquetes 0-RTT recibidos. Si omite la extensión, rechaza 0-RTT y no debe procesar esos paquetes como datos aceptados.

La secuencia tiene valor probatorio, pero su alcance termina en la frontera criptográfica y de transporte. No demuestra que un manejador de aplicación se ejecutó exactamente una vez. Tampoco prueba que la solicitud alcanzara un servicio posterior, atravesara un límite de persistencia o produjera un resultado para el cliente. Antes de terminar el handshake, no prueba por sí sola que el cliente siga activo o esté autenticado. La validación de dirección puede aportar contexto, pero no elimina la posibilidad de replay.

QUIC 0-RTT hereda la exposición al replay de los datos tempranos de TLS. Las mitigaciones de TLS son necesarias, aunque no sustituyen la política de la aplicación. El procesamiento básico de las tramas QUIC es idempotente: repetir tramas no crea por sí mismo un estado de conexión inválido. El riesgo está en el significado de los datos transportados. STREAM, RESET_STREAM, STOP_SENDING y CONNECTION_CLOSE pueden tener significado de aplicación y ser inseguros en 0-RTT. Cada protocolo que use QUIC debe definir un perfil de uso aceptable.

HTTP muestra cómo comunicar esa condición. Cuando no hay información mejor, el cliente puede usar métodos seguros en datos tempranos y no debe usar métodos inseguros o de seguridad desconocida. Early-Data informa que un intermediario propagó una solicitud bajo esas condiciones. 425 Too Early expresa que el servidor no quiere arriesgarse a procesar una solicitud que podría repetirse. El reintento no debe usar a su vez datos tempranos. Esperar al handshake después de que un intermediario marque Early-Data no vuelve segura la solicitud retroactivamente, y las instancias distribuidas deben actuar de forma uniforme.

El registro de evidencia debe separar el ticket de sesión y la configuración recordada; 0-RTT intentado, aceptado o rechazado; ACK de paquetes; propagación de Early-Data y tratamiento de 425; identidad de solicitud y clave de idempotencia; intentos de ejecución; efectos secundarios; recibo de commit durable; observaciones de reintento o replay; y resultado del cliente o financiero. Las claves de idempotencia, los diarios transaccionales y los registros distribuidos son recomendaciones operativas, no requisitos de QUIC salvo que el protocolo de aplicación los establezca.

La conclusión práctica es restringir 0-RTT a operaciones con consecuencias de replay explícitamente acotadas. Desactivarlo ofrece la defensa más eficaz, pero no es necesario para toda operación. La aceptación de datos tempranos acredita una decisión de transporte; nunca debe presentarse como confirmación de una transacción.