Resumo

  • A revisão 01 do rascunho MBONED é um Internet-Draft informativo ativo; não é RFC, produto implantado nem resultado de interoperabilidade.
  • A entrega individual da chave autentica e autoriza um receptor naquele momento, mas uma chave comum amplia o conteúdo exposto quando um dispositivo é comprometido.
  • Decriptar não prova a fonte; cada unidade precisa de assimetria de autenticação para impedir que um detentor da chave compartilhada fale como o emissor.
  • Rotação, descarte, sequência, vínculo ao pedido, permissão do navegador e efeito observado exigem recibos independentes.

A admissão individual termina antes do risco coletivo

O provedor pode autenticar cada receptor por um canal unicast protegido, avaliar sua assinatura e só então entregar a chave multicast. Esse processo é importante: limita quem recebe material de decriptação. Mas o resultado seguinte é coletivo. Vários aparelhos guardam uma chave capaz de abrir o mesmo fluxo.

Quando um deles cai, o invasor herda a janela daquela época. Não é preciso romper todas as sessões TLS nem comprometer a origem. O raio de exposição é definido pelo conteúdo coberto pela chave, pela duração da época e pela eficiência real de retirada.

Uma lista de assinantes não mede esse raio. O inventário precisa mostrar qual segredo cada aparelho recebeu, que conteúdo ele cobria, quando foi instalado, quando deixou de ser usado pelo emissor e quando foi apagado no receptor. “Membro removido” é uma decisão administrativa; não é uma prova de exclusão criptográfica.

Sigilo futuro depende de uma cadeia inteira

O rascunho descreve como o sigilo futuro pode ser aproximado: receptores são autenticados e autorizados individualmente; as chaves de grupo são entregues por um transporte unicast com sigilo futuro, como TLS 1.3; as chaves multicast são efêmeras, giradas e descartadas.

O benefício é temporal. Se a chave de longo prazo for comprometida mais tarde, épocas antigas não devem ser recuperáveis por ela. Mas o intervalo da chave multicast continua sendo a unidade de exposição. Quem obteve a chave da época pode ler o conteúdo protegido por ela enquanto a possuir.

Configurar rotação a cada dez minutos não prova que o emissor cortou no limite, que todos os receptores apagaram a época anterior ou que um cache não a reteve. A política de tempo e a evidência de descarte são objetos diferentes.

A chave que abre não identifica quem falou

Uma construção simétrica ingênua pode usar material compartilhado tanto para decriptar quanto para validar etiquetas. Quem conhece a chave pode produzir uma etiqueta correta. Em um grupo, isso pode incluir um receptor autorizado que esteja no caminho ou consiga falsificar a origem.

O desenho precisa introduzir assimetria por unidade de conteúdo. Assinaturas mantêm a chave de assinatura no emissor. TESLA libera material simétrico depois que os dados deveriam ter chegado. AMBI distribui um manifesto autenticado e ordenado de resumos por um canal fora da banda.

Nenhuma opção elimina a governança. A assinatura exige procedência da chave pública. TESLA exige relógio, janela e espera. O manifesto exige autenticidade do canal, cobertura e tratamento de lacunas. O painel deve registrar qual propriedade foi verificada, não apenas “criptografia ligada”.

Autenticar no fim pode ser tarde

Se o objeto inteiro só for conferido depois da montagem, um pacote injetado pode consumir memória, ordenação, correção e decodificação antes de invalidar o resultado. Muitos receptores podem então pedir recuperação unicast, multiplicando o custo imposto ao provedor.

Autenticação por pacote permite rejeitar mais cedo. Ainda assim, UDP não entrega confiabilidade, ordem, deduplicação ou defesa nativa contra repetição. Números de sequência, intervalos TESLA ou manifestos precisam expor duplicação, reordenação e exclusão.

Para o navegador, o ponto de liberação importa. Dados apenas decriptados não devem chegar a parsers ou renderizadores. A decisão de fonte e os controles de sequência e pedido têm de terminar antes do uso, não apenas antes de um relatório posterior.

O pedido não viaja no canal multicast

Em HTTPS unicast, pedido e resposta pertencem a uma troca protegida. Multicast é naturalmente unidirecional e não transporta o pedido individual. Dois canais podem ser legítimos e assinados pela mesma fonte, mas responder a objetos diferentes.

Sem vínculo criptográfico adicional, um adversário no caminho pode trocar pacotes entre dois canais confiáveis. A assinatura permanece válida se cobrir somente fonte e pacote. Falta a afirmação de que os dados correspondem ao pedido específico do cliente.

Fonte, unidade, pedido, autorização de uso e resultado são cinco estados. Uma contagem de pacotes válidos não pode provar que o vídeo certo foi exibido, que o usuário tinha direito a ele ou que a aplicação o aceitou.

O observador ainda vê um grupo

Criptografia esconde a carga de quem não tem a chave. Não apaga tamanho, tempo, endereços e padrões. Em multicast, um observador no caminho pode determinar que conteúdo idêntico foi entregue a múltiplos ramos, mesmo sem saber o que ele significa.

IGMP ou MLD também podem mostrar que alguma entidade abaixo daquele ponto aderiu a um canal. Isso pode oferecer uma forma limitada de ambiguidade sobre qual usuário está por trás do roteador, mas não é anonimato. Ao migrar entre redes, a assinatura do canal pode ser correlacionada com fluxos de controle unicast cifrados.

Por isso dados pessoais confidenciais são um ajuste ruim para a natureza do multicast. A vantagem econômica vem da mesma informação ir para muitos; a privacidade não pode ser inferida do fato de a carga estar cifrada.

Navegador e rede têm controles diferentes

Uma origem hostil pode mandar o navegador aderir a muitos canais. O navegador deve limitar associações à origem hospedeira ou exigir autorização explícita entre origens. Essa barreira protege o usuário de um site, mas não reserva capacidade de rede.

O roteador a montante pode observar leques abusivos e aplicar um disjuntor em sobrecarga, talvez retirando conteúdo pouco popular. Ele protege recursos compartilhados; não certifica a fonte nem decide a autorização da aplicação.

No modo privado, a adesão expõe metadados à rede. O rascunho recomenda aprovação explícita. Essa aprovação autoriza o ato observável, não garante anonimato, integridade do fluxo ou resultado humano.

Métricas devem mostrar a época

Registrar “sessões seguras” não basta. O livro precisa separar receptores aprovados, chaves entregues, instalações confirmadas, épocas ativas, unidades decriptadas, unidades autenticadas, repetições, lacunas, pedidos vinculados, permissões de origem, liberações ao parser e resultados.

O raio de comprometimento deve ser consultável por época: número de receptores, conteúdo coberto, duração, aparelhos ainda ativos, tempo de corte do emissor e evidência de descarte. Segredos e conteúdo pessoal não entram no log; identificadores podem ser resumidos.

Alarmes incluem aceitação depois da retirada, material antigo em uso, um segredo simétrico servindo de prova de fonte sem assimetria, uso antes da autenticação, manifesto incompleto, recuperação ampliada e mudança anormal de rede durante a adesão.

Fontes e limites

O pacote congelado contém a revisão 01 e os registros de status, histórico e referências; o grupo MBONED; RFCs de ameaças da Internet e UDP; SSM e a retirada do ASM entre domínios; TLS 1.3; TESLA, NORM, ALC e autenticação multicast; segurança WebRTC, Client Hints, QUIC, WebTransport e AMBI.

Essas fontes estabelecem texto e estado oficiais. Não estabelecem conformidade, adoção, desempenho, um aparelho realmente comprometido, falsificação, incidente de privacidade ou resultado exibido. A abertura é um cenário construído para testar o raio de autoridade.

Fontes