Resumo

  • draft-ietf-tls-pake-02 é uma moldura para vários esquemas e dois modos de integração; dizer apenas que PAKE foi ativado não informa qual segredo, registro, identidade ou confirmação sustentou a sessão.
  • A seleção de esquema não prova a existência da conta, e o Finished não substitui certificado, autorização, ciclo de vida do registro nem avaliação pós-quântica da senha.

O painel de segurança mostrava uma única marca verde: “PAKE ativado”. Uma região usava SPAKE2+ com registro aumentado. Outra mantinha um segredo compartilhado para um esquema balanceado. Uma terceira executava um PAKE externo e importava sua saída como PSK. Só alguns serviços exigiam certificado.

O mesmo selo descrevia promessas diferentes.

A revisão 02 de draft-ietf-tls-pake, publicada em 6 de julho de 2026 e válida até 7 de janeiro de 2027, propõe uma extensão genérica para TLS 1.3. É um Internet-Draft Informational ativo do grupo TLS, não RFC, registro definitivo, auditoria, implantação ou aprovação de produto. O próprio texto adverte que ainda não recebeu análise de segurança significativa.

O problema do PSK de baixa entropia

O binder de PSK do TLS 1.3 permite testar candidatos quando o segredo é uma senha humana. Por isso, a proposta não coloca a senha diretamente no PSK. Ela transporta mensagens de um PAKE e combina o segredo resultante com o key share efêmero comum no cronograma de chaves.

O cliente oferece uma lista ordenada de PAKEShare, cada uma para um esquema, junto com uma única dupla de identidades. O servidor escolhe uma opção compatível, consulta material de registro e devolve sua participação.

Cada palavra dessa descrição muda a garantia. SPAKE2+ é aumentado: o servidor trabalha com um registro derivado, não necessariamente com a senha. Outros esquemas podem ser balanceados. Alguns são clássicos; outros pretendem propriedades pós-quânticas. Um controle que registra apenas pake=true apaga o modelo de custódia.

Suporte ao esquema não é registro da conta

O servidor pode reconhecer o identificador do esquema e não encontrar a dupla de identidades. Nesse caso, o rascunho permite simular uma resposta plausível para evitar enumeração.

O ServerHello prova que uma ramificação PAKE foi selecionada. Não prova que havia conta. O cliente sem o segredo correspondente falhará no Finished. É justamente por isso que um coletor não pode contar ServerHello como autenticação aceita.

A simulação precisa alcançar os canais laterais: tempo, alerta, tamanho, uso de CPU, consulta ao banco, cache e rate limit. A igualdade sintática dos shares não demonstra igualdade operacional. Cada implementação deve testar essa fronteira.

O modo com certificado é outro produto

O cliente pode oferecer signature_algorithms junto com PAKE. Se o servidor selecionar PAKE, nesse caso envia Certificate e CertificateVerify. PAKE sozinho e PAKE mais certificado não fazem a mesma afirmação sobre o servidor.

Além disso, server_identity do PAKE é separado de SNI. Um pode indexar o registro; o outro pode rotear para um virtual host. O certificado valida uma identidade de referência sob política PKI. O produto precisa declarar a regra de correspondência entre os três.

Uma frase como “autenticação mútua” não resolve isso. É necessário registrar se o cliente exigiu certificado, qual nome foi validado e que identidade PAKE entrou no transcript. Conhecer a senha não transforma automaticamente um hostname em verdadeiro.

Finished encerra uma etapa, não a autorização

O segredo PAKE entra no cronograma junto com (EC)DHE. Os Finished confirmam o transcript. Para o servidor, o cliente só está autenticado depois que o Finished do cliente é validado; antes disso, não deveria receber dados de aplicação.

Após esse ponto, ainda falta autorização. A conta pode estar suspensa, a senha pode ser compartilhada, o reset pode ter sido aprovado pela pessoa errada ou o recurso pode exigir outro fator. Finished demonstra posse criptográfica nesta sessão, não direito comercial.

O recibo precisa separar seleção, lookup, Finished, primeira carga útil, principal de aplicação, decisão de política e resultado externo. Um único evento login_ok deixa todos os donos de controle invisíveis.

Integração externa muda a cadeia de custódia

PAKEs internos precisam caber em ClientHello e ServerHello. Esquemas com mais mensagens executam antes do TLS e importam a saída como PSK usando RFC 9258.

O handshake posterior confirma a chave importada. Não prova sozinho qual transcript a produziu, quem era o par, quais identidades foram usadas ou se o channel binding correto entrou no contexto.

RFC 9258 separa a chave por protocolo, KDF e contexto. A aplicação continua responsável por fornecer os dados corretos e correlacionar a execução anterior com a conexão consumidora. Sem hash do transcript e identidade importada, o selo verde cobre apenas a metade final.

Pós-quântico para tráfego não é pós-quântico para senha

Um key share híbrido pode proteger o tráfego gravado contra descriptografia futura. Se o PAKE for clássico, suas próprias mensagens podem permitir recuperação retroativa de uma senha longa quando as hipóteses clássicas caírem.

O dano é prospectivo: a senha recuperada pode autenticar sessões futuras até a rotação, mesmo que o tráfego antigo continue confidencial. A organização deve acompanhar separadamente proteção do tráfego e longevidade da credencial.

O rascunho inclui caminhos OQUAKE e OQUAKE+ e referencia uma composição híbrida externa. Essas dependências permanecem documentos de pesquisa em evolução. O painel não pode convertê-las em certificação por simples presença do nome.

Registro e recuperação ficam fora do handshake

Antes da conexão, alguém provisionou senha ou verificador, identidades, sal e parâmetros. O rascunho não especifica prova de identidade no cadastro, reset, revogação, migração ou descarte.

Uma sessão perfeita pode autenticar um registro criado de forma errada. A migração pode deixar dois verificadores válidos. Um suporte pode redefinir a credencial sem evidência suficiente. São falhas reais, mas não são falhas do Finished.

O inventário deve associar versão do registro, esquema, autoridade que aprovou, data de rotação e destruição do material anterior. Sem isso, a etiqueta PAKE mede capacidade criptográfica, não governança da identidade.

O painel deve mostrar promessas, não marcas

A extensão genérica tem valor porque permite evoluir esquemas e combinar PAKE com o TLS existente. Essa flexibilidade torna a telemetria mais importante, não menos.

Um painel útil informa: esquema e versão; balanceado ou aumentado; interno ou externo; certificado exigido; Finished validado; tráfego PQ; PAKE PQ; versão do registro; autorização concedida. Também mostra estados desconhecidos e recusas.

“PAKE ativado” pode continuar como resumo comercial, mas nunca como evidência operacional. Quando ocorre um incidente, a organização precisa saber qual promessa falhou, qual continuou válida e quem controlava a etapa.

Fontes