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.