Resumo

  • O texto atual é draft-ietf-tls-extended-key-update-13; a revisão 11 ficou para trás e o documento continua sendo um Internet-Draft, não um RFC aprovado nem evidência de implantação.
  • Request, response e finish podem inserir material criptográfico novo, mas cada etapa é apenas um recibo parcial: não atesta o apagamento local nem a mudança completa das duas direções.
  • Uma conclusão defensável precisa ligar negociação, sequência, geração efêmera, derivação, destruição do estado antigo, primeira aceitação em cada sentido e teste de aplicação de ida e volta.

A versão mudou, o estatuto continua provisório

O Datatracker da IETF marca a revisão 11 como antiga. A revisão 13, publicada em 4 de julho de 2026, expira em 5 de janeiro de 2027. O status pretendido é Proposed Standard, mas o estado na IESG permanece “I-D Exists”, sem Area Director responsável ou data de telechat.

A revisão 13 renomeou o subtipo 2 para key_update_finish, esclareceu que as três mensagens usam as chaves antigas e ampliou a discussão do atacante ativo. Uma alegação de suporte deve registrar a revisão e o comportamento visto. “Padrão aprovado pela IETF” seria uma descrição falsa.

Suporte, habilitação e negociação não são sinônimos

O cliente propõe Extended_Key_Update nos TLS flags do ClientHello. O servidor confirma em EncryptedExtensions somente se houver suporte e configuração. Sem a confirmação, uma aplicação que exija segurança pós-comprometimento precisa executar um handshake completo.

Depois do acordo, o KeyUpdate clássico fica proibido e causa unexpected_message. Request e response devem usar o grupo escolhido no handshake original; outro grupo causa illegal_parameter. A presença do código, a decisão de política e o acordo desta sessão geram recibos diferentes.

A virada acontece por direção

O iniciador envia key_update_request com um key share efêmero. O respondedor devolve key_update_response e muda primeiro a chave de envio. O iniciador deriva o novo estado, muda a recepção, envia um key_update_finish vazio ainda protegido pela chave antiga e só então muda o envio. O respondedor muda a recepção após autenticar esse finish antigo.

Durante essa janela, cada endpoint mantém gerações distintas para enviar e receber. Um único campo “versão da chave da conexão” esconde o estado real. Pedidos cruzados são resolvidos pelo valor lexicograficamente menor de key_exchange, que perde; igualdade encerra a conexão.

A derivação combina o segredo compartilhado novo, um valor ligado ao main secret anterior e um transcript hash do handshake e das trocas EKU. Ela produz os dois segredos de tráfego, o exporter secret e o resumption main secret. Esse ingrediente novo impede que o sucessor seja função apenas da cadeia comprometida.

A fronteira que a rede não enxerga

Um trace pode mostrar novos shares e registros compatíveis. Não prova a saúde do gerador aleatório, ausência de reutilização, nem a eliminação de cópias em heap, HSM, kernel ou crash dump. O rascunho diz que a implementação DEVERIA apagar os segredos anteriores assim que possível; o peer remoto não pode atestar essa ação.

O recibo útil precisa juntar, sem expor chaves: revisão e grupo negociados, identificador não secreto da geração efêmera, identificadores de request/response/finish, geração dos segredos sucessores, resultado de destruição em cada camada e o primeiro registro aceito sob a nova chave em cada sentido.

A hipótese também exige que o atacante tenha perdido acesso aos dois peers. Um invasor persistente lê o estado novo; um adversário ativo com as chaves atuais pode substituir mensagens e preservar um MitM, a menos que a autenticação adicional da seção 11 seja usada e tenha sucesso. Recuperar uma conexão não corrige uma chave de identidade de longo prazo comprometida.

No DTLS, epochs, retransmissões, retenção temporária do estado antigo e ACKs mudam a evidência. O iniciador só conclui a troca de envio após receber o ACK sob o novo epoch. Telemetria de TLS não prova isso por analogia.

Fontes