Resumo

  • A revisão 25 exige confidencialidade e integridade para Claims criptografados e proíbe o uso isolado do ChaCha20, porém o Marker não informa identidade, mandato nem titularidade do endereço.
  • Nós com chave e sem chave podem formar universos de detecção de colisão que não se enxergam; mesmo dentro do grupo autenticado, uma mensagem válida só demonstra acesso ao material criptográfico aceito.

Há uma diferença decisiva entre silêncio e ausência. Um nó pode não receber nenhuma declaração porque o endereço está livre. Também pode não receber porque a declaração foi cifrada com outra chave. Se o sistema trata os dois casos como equivalentes, a proteção da mensagem passa a esconder justamente a evidência necessária para evitar uma colisão.

O rascunho GAAP na revisão 25 descreve uma coordenação descentralizada e leve dentro de um domínio administrativo. A aplicação calcula um endereço candidato a partir do hash do Group Name. Quando nomes diferentes reivindicam o mesmo endereço, existe colisão; o participante pode tentar outras três posições determinísticas, acrescentando 1, 2 ou 3 ao nome. Um Claim inicial é seguido por uma espera de aproximadamente um intervalo periódico, e Claims regulares mantêm o estado temporário. Para liberar, o emissor simplesmente para.

O estágio do documento limita qualquer afirmação. O Datatracker da IETF mostra uma proposta Experimental em IESG Evaluation, AD Followup. O histórico registra trabalho editorial e técnico, não adoção. O próprio texto reconhece que o modelo distribuído baseado em hash não foi implantado e que colisões e comportamento em escala ainda não foram medidos.

Uma melhoria de segurança que merece precisão

Na revisão 23, a leitura da proteção criptográfica era menos rigorosa. A revisão 25 determina que um Claim cifrado use um mecanismo com confidencialidade e integridade, como AEAD. Também declara que ChaCha20 sozinho não deve ser empregado. RFC 8439 esclarece o motivo: sem autenticação, a maleabilidade da cifra de fluxo permite modificar o texto cifrado e provocar alterações previsíveis no endereço, no timestamp ou no Group Name após a decifragem.

O nonce deve ser único por chave em todos os emissores que a compartilham. E um receptor configurado com chave precisa rejeitar Claims em claro, evitando uma queda silenciosa para o modo desprotegido. São exigências relevantes e corretas.

Ainda assim, o Marker é só um sinal implícito de criptografia. Ele não transporta uma identidade pública nem a origem da autorização. Método, chave, estrutura do registro, associated data, desenho de nonces e troca dinâmica de chaves ficam em grande parte fora do protocolo. Quando a decifragem falha, o registro é descartado. Chave errada, mecanismo incompatível, corrupção e ataque podem produzir exatamente o mesmo resultado observável.

Daí surge a fronteira de visibilidade. Nós com chave recusam a declaração aberta; nós sem chave não interpretam a cifrada. Duas populações na mesma rede física podem acreditar, com lógica interna coerente, que o endereço está disponível. A autenticação protege o que cada uma vê, mas não amplia o campo de visão.

Participação técnica não é autorização

Mesmo no interior de um único grupo de chaves, o problema de legitimidade permanece. Um participante malicioso que já possua o segredo pode criar um Claim perfeitamente autenticado. A comparação de timestamps e a regra determinística de desempate produzem um vencedor do protocolo; não provam boa-fé.

O tratamento cauteloso da Bad Actor List confirma esse limite. Ela é local, limitada e indicativa, pois endereços de origem podem ser falsificados e perder uma disputa temporal não demonstra comportamento hostil. RFC 1982 fornece a aritmética de números seriais, enquanto RFC 8085 orienta o uso de UDP. Nenhum dos dois cria um título sobre recursos.

Os documentos sobre escopos e mecanismos anteriores—RFC 2365, RFC 5771, RFC 2730 e RFC 2909—dão o contexto histórico. RFC 10019 e RFC 10028 expõem a arquitetura atual e a lacuna que motiva alternativas. A inferência, porém, deve continuar estreita: criptografia valida a mensagem; GAAP compara Claims visíveis; uma regra externa decide quem podia reivindicar.

O poder que aparece fora da especificação

A defesa de Heng Lu de uma especificação inicial mínima, decisão futura localizada e adoção voluntária combina com a natureza experimental do GAAP. É sensato testar uma coordenação delimitada antes de construir uma instituição ampla.

Mas tudo que fica fora do protocolo precisa ganhar nome. Distribuir a chave é admitir membros. Revogá-la é excluir. Definir a população capaz de decifrar é definir quais colisões contam como realidade comum. Sem uma separação consciente, o administrador da chave vira o regulador prático do conjunto de endereços.

A primazia do código em execução exige observar o sistema real: quais Claims chegam aos receptores, o que ocorre após uma rotação incompleta, quem identifica populações sobrepostas e quem responde pela interrupção. O rótulo “criptografado” não substitui essas respostas.

O artigo anterior da BTW sobre GAAP-23, faixas corrigidas e convergência após partições examinou como o mesmo nome pode continuar em endereços alternativos diferentes depois da reconexão. A revisão 25 não resolve aquele ponto. Ela evidencia outro: chaves divergentes podem produzir uma partição lógica mesmo quando os enlaces permanecem íntegros.

O GAAP-25 entrega um envelope melhor. Cabe à operação impedir que a capacidade de abri-lo seja confundida com o direito ao conteúdo.

Fontes