Resumo

  • A versão 00 do rascunho descrevia uma variante de quatro mensagens que punha ID_CRED_I em texto aberto na primeira mensagem e, segundo o próprio documento, sacrificava a proteção da identidade do iniciador. A versão 01 não contém mais essa variante.
  • O texto de 28 de setembro enumera cinco mensagens obrigatórias. Para o respondedor, a autenticação do iniciador e a derivação de chaves de aplicação dependem da verificação da quinta mensagem.
  • O valor de método 5 continua apenas sugerido. A proposta não torna qualquer KEM resistente a computadores quânticos: isso depende de uma instanciação com algoritmo pós-quântico apropriado.

A disputa entre rapidez e privacidade aparece com nitidez quando se leem as duas versões, não quando se olha apenas o nome do protocolo. Em julho, a seção 6.3 oferecia uma redução do fluxo: o iniciador colocaria o identificador de sua credencial em message_1, sem criptografia, para que o respondedor tivesse mais cedo a informação associada à chave estática. Assim seria possível eliminar message_5. O documento reconhecia explicitamente o custo: menor proteção da identidade do iniciador. Não descrevia um vazamento observado em uma rede nem a adoção dessa variante por fabricantes.

Na revisão 01, de 28 de setembro, a seção desapareceu. O fluxo especificado vai de message_1 a message_5_KEM, com as cinco mensagens classificadas como obrigatórias. Não se trata da invenção de um novo fluxo de cinco mensagens; ele já era a proposta principal da versão 00. A notícia é a retirada, deste rascunho, do caminho abreviado com sacrifício explícito de privacidade. A comparação textual não revela a motivação dos autores e não prova que um protocolo de quatro mensagens seja impossível em qualquer circunstância.

O quinto passo existe por uma razão funcional. Quem possui uma chave privada KEM estática precisa antes receber um texto encapsulado para a chave pública correspondente; só então consegue demonstrar posse do segredo associado. O rascunho calcula que essa dependência pode acrescentar até uma ida e volta. Na sequência proposta, message_4_KEM leva a confirmação do respondedor, e message_5_KEM permite ao respondedor verificar o iniciador. O iniciador pode derivar chaves de aplicação depois de receber a quarta mensagem e formar a quinta. O respondedor chega a esse estado após verificar a quinta. Um único indicador de “conexão autenticada” para ambos os lados ocultaria essa diferença temporal.

Há também uma decisão de confiança antes da própria divulgação cifrada. O iniciador precisa validar e aceitar, segundo sua política local, a credencial do respondedor antes de enviar sua credencial no terceiro passo. A exigência já constava da versão de julho. Ela evita confiar apenas na validade criptográfica de uma credencial pertencente a um destinatário que não era o pretendido. Criptografar a identidade não substitui escolher corretamente a contraparte; e validar essa contraparte não substitui concluir a autenticação mútua.

O alcance do pedido à IANA ficou menor. A versão 00 sugeria números para algoritmos ML-KEM em COSE, suítes EDHOC e um tipo de método. A seção 7 da versão 01 contém somente a proposta de um tipo de método, identificado como “5 (suggested)”, e referencia trabalhos separados sobre representação de KEM e suítes resistentes a ataques quânticos. Isso não demonstra que a IANA tenha feito a atribuição nem que os documentos citados estejam aprovados. Os autores agora acentuam que o método é independente de um KEM específico; a segurança pós-quântica é condicional à escolha concreta do algoritmo.

Quem avalia a atualização de dispositivos limitados deve perguntar qual identidade fica visível, qual suíte foi negociada, em que momento cada ponta aceita a sessão e o que acontece se a quinta mensagem não chega. É uma pauta de testes proposta por Daniel Kade, não uma obrigação operacional recém-criada pela IETF. O documento continua sendo um Internet-Draft ativo, sem dados sobre implantação, desempenho real ou incidentes.

Fontes