I5SL-DRAFT-01 — Internet 5.0 Session Layer

Internet 5.0 Initiative                                      A. F. Rodrigues
Request for Comments: I5SL-DRAFT-01                         Independent
Categoria: Informativo                                       27 maio 2026

              Internet 5.0 Session Layer (I5SL)
       Camada de Sessão para Disponibilidade, Confidencialidade,
          Integridade, Privacidade e Resistência à Censura

Status deste Memorando

   Este documento é um draft informativo independente, inspirado no formato
   de Request for Comments. Ele NÃO é uma RFC oficial da IETF, não representa
   consenso da IETF e não possui status normativo internacional. Seu objetivo
   é abrir comentários técnicos, jurídicos e acadêmicos.

Convenções usadas neste documento

   As palavras-chave MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY e OPTIONAL devem ser interpretadas conforme
   BCP 14, RFC 2119 e RFC 8174 quando aparecerem em letras maiúsculas.

Resumo

   Este documento especifica, em nível conceitual, a Internet 5.0 Session
   Layer (I5SL), uma camada de sobreposição entre aplicações e transporte,
   destinada a fornecer sessões seguras, identidade criptográfica, resolução
   de nomes resistente à censura, múltiplos localizadores, autenticação de
   conteúdo, minimização de metadados, proteção contra downgrade e rotas
   alternativas de acesso.

1. Introdução

   A censura estatal moderna explora pontos de estrangulamento da internet,
   incluindo DNS, registradores, provedores de acesso, sistemas autônomos,
   lojas de aplicativos, plataformas, serviços de nuvem e metadados expostos.
   A I5SL não substitui IP, TCP, UDP, TLS ou QUIC. Ela define uma camada de
   sessão e política que permite às aplicações estabelecer comunicação por
   identidade verificável e por múltiplos caminhos de acesso.

2. Objetivos

   A I5SL tem cinco objetivos principais:

   1. Disponibilidade: preservar acesso a informações legítimas sob bloqueios.
   2. Confidencialidade: proteger o conteúdo por criptografia forte.
   3. Integridade: permitir verificação criptográfica de nomes e conteúdos.
   4. Privacidade: minimizar metadados expostos a intermediários.
   5. Resistência à censura: tornar bloqueios seletivos difíceis, caros,
      detectáveis e politicamente visíveis.

3. Modelo de ameaça

   A I5SL considera adversários capazes de bloquear DNS, IPs, portas,
   protocolos, aplicações ou lojas de aplicativos; adulterar respostas DNS;
   degradar tráfego; classificar metadados; pressionar provedores,
   registradores e operadores; emitir ordens amplas de bloqueio; ou tentar
   downgrade para conexões menos seguras.

   A I5SL não promete proteção contra desligamento total de energia, corte
   físico de cabos, prisão de operadores, proibição legal absoluta ou controle
   completo de dispositivos pelos governos.

4. Requisitos normativos

   I5SL-REQ-01: Uma implementação MUST preservar compatibilidade progressiva
   com a internet existente.

   I5SL-REQ-02: Uma implementação MUST permitir identidade criptográfica
   independente de domínio tradicional.

   I5SL-REQ-03: Uma identidade I5SL SHOULD poder publicar múltiplos
   localizadores assinados, incluindo domínio tradicional, registros DNSSEC,
   onion service, identificadores de conteúdo, mirrors, relays e caches.

   I5SL-REQ-04: Uma implementação MUST oferecer proteção contra downgrade.

   I5SL-REQ-05: Uma implementação SHOULD minimizar exposição de metadados,
   inclusive consultas de nomes, destino pretendido e padrões identificáveis.

   I5SL-REQ-06: Uma implementação MUST NOT conter backdoor, chave mestra,
   escrow obrigatório, descriptografia universal ou mecanismo central de
   censura.

   I5SL-REQ-07: Conteúdos espelhados SHOULD ser verificáveis por assinatura
   criptográfica ou hash de conteúdo.

   I5SL-REQ-08: Uma implementação MAY usar transportes adaptativos, relays,
   onion services, caches distribuídos, P2P ou outros mecanismos compatíveis
   com a política de sessão.

   I5SL-REQ-09: A governança ética MUST ser implementada sem fragilizar
   criptografia, identidade, integridade, disponibilidade ou privacidade.

5. Arquitetura

   A I5SL consiste nos seguintes módulos:

   - Módulo de identidade criptográfica.
   - Módulo de nomes resistentes à censura, definido no I5NS.
   - API de sessão segura.
   - Módulo de múltiplas rotas.
   - Módulo de integridade e espelhamento.
   - Módulo de transportes adaptativos.
   - Camada de governança ética e transparência.

6. API conceitual

   Uma API conceitual poderia expor:

      secure_session(identity, policy, content_type)

   Onde identity identifica a fonte por chave pública ou identificador
   derivado; policy define requisitos de privacidade, rota, integridade e
   fallback; e content_type descreve a natureza da sessão.

7. Governança ética

   A I5SL não se destina a proteger crimes, violência, fraude, exploração de
   vulneráveis ou abuso de direitos. Entretanto, a resposta a ilícitos SHOULD
   ocorrer nas bordas, por investigação individualizada, devido processo,
   moderação de aplicação, sinais de confiança, listas plurais de reputação,
   proteção de vítimas e responsabilização dos autores.

   A camada de protocolo MUST NOT incluir lista global obrigatória de censura,
   autoridade central de revogação política, backdoor criptográfico ou
   mecanismo de bloqueio remoto universal.

8. Considerações de segurança

   Implementações devem considerar ataques de downgrade, enumeração de
   identidades, correlação de tráfego, comprometimento de chaves, mirrors
   maliciosos, relays hostis, negação de serviço, captura de listas de
   reputação e coerção estatal contra operadores.

9. Considerações de privacidade

   A I5SL deve minimizar coleta e exposição de metadados. Nenhum componente
   deve reunir, sem necessidade, identidade civil, endereço IP, consulta de
   nome, destino pretendido e conteúdo acessado.

10. Considerações legais

   A I5SL deve ser analisada à luz de liberdade de expressão, privacidade,
   proteção de dados, devido processo, proporcionalidade e direitos humanos.
   Ordens estatais de restrição não devem ser tratadas como automaticamente
   legítimas quando produzirem bloqueios amplos, quebra generalizada de
   criptografia, punição de terceiros inocentes ou censura política.

11. Referências

   RFC 2119, RFC 8174, RFC 8446, RFC 9000, RFC 8484, RFC 7858, RFC 9230,
   RFC 9849, RFC 7686, RFC 4033, documentação IPFS, especificações Nostr,
   documentos da ONU sobre liberdade de expressão e relatórios #KeepItOn.