Resumo

  • A aceitação de QUIC 0-RTT é uma decisão de TLS e transporte, não prova de execução única na aplicação.
  • Um ACK prova processamento do transporte, mas não entrega à aplicação, commit durável, identidade autenticada ou sucesso comercial.
  • O protocolo da aplicação deve limitar o uso de dados antecipados e manter evidências separadas de execução, idempotência, efeitos e resultado.

QUIC 0-RTT permite que o cliente reutilize configurações associadas a uma conexão anterior, inclusive um ticket de sessão TLS, para enviar dados de aplicação antes de o novo handshake terminar. O servidor aceita essa modalidade ao enviar a extensão TLS early_data em EncryptedExtensions. Em seguida, processa e confirma os pacotes 0-RTT recebidos. Se não enviar a extensão, rejeita o 0-RTT e não deve processar esses pacotes como dados antecipados aceitos.

A cadeia demonstra uma decisão criptográfica e de transporte, nada além. Ela não prova que um manipulador da aplicação executou a ação exatamente uma vez, que a requisição chegou a um serviço downstream ou que atingiu um ponto de persistência durável. Também não prova, antes do fim do handshake, que o cliente está ativo ou autenticado. A validação de endereço pode acrescentar evidência, mas não transforma uma requisição sujeita a replay em uma ação empresarial única.

QUIC 0-RTT herda a exposição a replay do early data de TLS. As mitigações de TLS são importantes, porém não substituem a responsabilidade da aplicação. O processamento das estruturas de transporte QUIC é idempotente; repetir frames não cria, por si só, um estado inválido da conexão. Os efeitos persistentes vêm do significado da aplicação carregado por esses frames. STREAM, RESET_STREAM, STOP_SENDING e CONNECTION_CLOSE podem transportar esse significado e ser perigosos em 0-RTT. Um protocolo de aplicação que use QUIC precisa definir um perfil de uso aceitável.

No HTTP, Early-Data sinaliza que uma solicitação foi encaminhada sob condições de dados antecipados. Sem informação melhor, o cliente pode usar métodos seguros e não deve usar métodos inseguros ou de segurança desconhecida. 425 Too Early informa que o servidor não quer arriscar o processamento de uma solicitação que pode sofrer replay. A nova tentativa não deve usar early data. Esperar o handshake depois de um intermediário marcar Early-Data não torna a solicitação segura retroativamente. Instâncias distribuídas precisam tratar essas solicitações de maneira consistente.

O livro-caixa de evidências deve separar ticket de sessão e configuração lembrada; 0-RTT tentado, aceito ou rejeitado; confirmação de pacotes; propagação de Early-Data e tratamento de 425; identidade da requisição e chave de idempotência; tentativas de execução; efeitos colaterais; recibo de commit durável; observações de replay ou retry; e resultado do cliente ou financeiro. Chaves de idempotência, diários transacionais e registros distribuídos são recomendações operacionais, não requisitos de QUIC, salvo especificação própria da aplicação.

A decisão adequada é restringir 0-RTT a operações cujas consequências de replay estejam explicitamente limitadas. Desativá-lo é a defesa mais forte contra replay, mas não é necessário para todas as operações. Aceitação é evidência de uma decisão de early data, não de uma transação concluída.