Resumo

  • Um Internet-Draft individual de 27 de outubro propõe que o receptor BPSec registre a fonte de segurança autorizada e sua chave para cada serviço exigido em cada bloco alvo. A prova de outro nó legítimo não substitui a da fonte esperada.
  • O BIB da própria carga útil deve abranger o bloco primário. Duas peças autenticadas separadamente podem ter vindo de bundles diferentes.

O intermediário também tinha crachá

É fácil imaginar o ataque errado: um estranho falsifica uma assinatura, a verificação falha e a história termina. O caso que interessa aqui é mais incômodo. O nó intermediário participa legitimamente da rede, possui sua própria chave e pode aplicar proteção em certos contextos. Ele retira a proteção da origem, troca o conteúdo e produz um novo Block Integrity Block, ou BIB, com a chave que de fato controla. Se o receptor perguntar apenas se um usuário legítimo produziu o bloco, ouvirá “sim”. O pacote do emissor já não é o mesmo.

A RFC 9172, seção 8.2.2, descreve essa substituição por um participante autorizado. A norma permite diferentes fontes de segurança num bundle e deixa a política de confiança ao ambiente de implantação. Proteger o BIB original com um Block Confidentiality Block, ou BCB, é uma mitigação do lado da origem. Ainda assim, um receptor que aceita um BCB produzido por qualquer fonte autorizada pode receber um conjunto refeito por outro nó legítimo. A assinatura está certa. A atribuição é que foi promovida sem licença.

O rascunho de N. D. S. Gupthaa dá ao receptor uma pergunta melhor. Para cada serviço de segurança exigido sobre cada bloco alvo, ele deve manter a fonte que tem autoridade naquela posição e a chave vinculada a ela. Um BIB ou BCB recebido só satisfaz a exigência se for verificado com esse material previamente registrado. A chave de outra fonte pode ser perfeitamente válida para outros serviços; não ocupa esta cadeira.

O IETF Datatracker registra a revisão 00 como Internet-Draft individual, sem aprovação formal da IETF ou trajetória de RFC. O texto propõe regras para aceitação. Não apresenta uma implantação identificada que já as execute.

Uma lista de pessoas confiáveis não define quem assina o quê

As regras R1 a R4 separam quatro deveres. R1 exige fonte e chave esperadas por serviço e bloco. R2 impede que um bloco de outra fonte conte como prova substituta, mesmo quando o nó é autorizado no restante da rede. R3 manda considerar falho o serviço obrigatório quando não há bloco correspondente. R4 impede que uma autorização para a estação intermediária voltar a proteger um fluxo vire autoridade sobre a carga de outro emissor.

R4 corta uma confusão perigosa: chamar um gateway de confiável sem dizer para quê. Encaminhar tráfego, proteger uma etapa e testemunhar uma origem delegada são mandatos diferentes. Um painel que resume tudo a “nó confiável” apaga a tarefa, o principal e o bloco que limitam cada mandato.

O campo Security Source do bloco recebido não resolve sozinho essa pergunta. A proposta o trata como uma pista de busca não confiável. A mensagem declara quem a produziu. A política local, definida antes da chegada, decide se aquela fonte era a esperada. Deixar o próprio bloco escolher a regra de aceitação seria permitir que o visitante escrevesse seu nome na lista de autorizados.

Há um limite físico para a separação. A RFC 9172 observa que uma chave comum a todos os nós torna qualquer detentor legítimo privilegiado quanto àquela chave. O receptor não pode identificar fontes distintas se a gestão de chaves as tornou indistinguíveis. Uma tabela de autorização elegante não conserta custódia compartilhada indiscriminadamente.

Duas provas verdadeiras, uma combinação inventada

A quinta regra trata de uma montagem diferente. Imagine um BIB sobre a carga útil e outro BIB separado sobre o bloco primário. Ambos podem verificar corretamente e até vir da mesma fonte, mas de dois bundles distintos. Verificar cada peça prova sua integridade individual; não prova que as peças nasceram juntas. Duas páginas assinadas não formam, por terem sido grampeadas, um contrato assinado como unidade.

R5 exige que o BIB da carga útil inclua o bloco primário no próprio escopo de integridade. A RFC 9173, seção 3.3.3, define o bit 0 para essa inclusão; a omissão do parâmetro usa o padrão 7, que também contém esse bit. Um BIB separado para o bloco primário não cria o vínculo ausente. A RFC 9171 define a estrutura do Bundle: o bloco primário carrega informações de identificação e processamento; o bloco de carga leva os dados da aplicação. Uma prova útil deve dizer se aquelas duas partes foram protegidas pelo mesmo cálculo.

O que a luz verde esconde

O rascunho menciona modelos formais em Tamarin e um verificador de configuração, com artefato ainda por publicar e disponível mediante pedido. A versão pública não permite reproduzir essa análise nem observar uma defesa em produção. Uma configuração inspecionável do receptor e um traço de substituição reproduzível mudariam essa avaliação.

Mesmo antes dessa prova adicional, o princípio operacional é claro. O receptor deve preservar a expectativa sobre fonte, serviço, bloco, chave e escopo antes de receber a prova. Exibir apenas “assinatura válida” deixa a equipe admirando o carimbo no pacote errado.

Fontes