Internet 5.0 Initiative A. F. Rodrigues Request for Comments: I5SL-DRAFT-01 Independent Category: Informational 27 May 2026 Internet 5.0 Session Layer (I5SL) A Session Layer for Availability, Confidentiality, Integrity, Privacy and Censorship Resistance Status of This Memo This document is an independent informational draft inspired by the Request for Comments format. It is NOT an official IETF RFC, does not represent IETF consensus and has no international normative status. Its purpose is to invite technical, legal and academic comments. Conventions Used in This Document The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in BCP 14, RFC 2119 and RFC 8174 when they appear in uppercase. Abstract This document specifies, at a conceptual level, the Internet 5.0 Session Layer (I5SL), an overlay layer between applications and transport designed to provide secure sessions, cryptographic identity, censorship-resistant name resolution, multiple locators, content authentication, metadata minimization, downgrade protection and alternative access paths. 1. Introduction Modern state censorship exploits Internet choke points, including DNS, registrars, access providers, autonomous systems, app stores, platforms, cloud services and exposed metadata. I5SL does not replace IP, TCP, UDP, TLS or QUIC. It defines a session and policy layer enabling applications to establish communication by verifiable identity and by multiple access paths. 2. Goals I5SL has five main goals: 1. Availability: preserve access to legitimate information under blocking. 2. Confidentiality: protect content with strong encryption. 3. Integrity: enable cryptographic verification of names and content. 4. Privacy: minimize metadata exposed to intermediaries. 5. Censorship resistance: make selective blocking difficult, expensive, detectable and politically visible. 3. Threat Model I5SL considers adversaries capable of blocking DNS, IPs, ports, protocols, applications or app stores; tampering with DNS responses; degrading traffic; classifying metadata; pressuring providers, registrars and operators; issuing broad blocking orders; or attempting downgrade to less secure connections. I5SL does not promise protection against total power shutdowns, physical cable cuts, arrest of operators, absolute legal prohibition or full state control of user devices. 4. Normative Requirements I5SL-REQ-01: An implementation MUST preserve progressive compatibility with the existing Internet. I5SL-REQ-02: An implementation MUST allow cryptographic identity independent of a traditional domain. I5SL-REQ-03: An I5SL identity SHOULD be able to publish multiple signed locators, including traditional domain, DNSSEC records, onion service, content identifiers, mirrors, relays and caches. I5SL-REQ-04: An implementation MUST provide downgrade protection. I5SL-REQ-05: An implementation SHOULD minimize exposure of metadata, including name queries, intended destination and identifiable patterns. I5SL-REQ-06: An implementation MUST NOT contain a backdoor, master key, mandatory escrow, universal decryption or central censorship mechanism. I5SL-REQ-07: Mirrored content SHOULD be verifiable by cryptographic signature or content hash. I5SL-REQ-08: An implementation MAY use adaptive transports, relays, onion services, distributed caches, P2P or other mechanisms compatible with the session policy. I5SL-REQ-09: Ethical governance MUST be implemented without weakening encryption, identity, integrity, availability or privacy. 5. Architecture I5SL consists of the following modules: - Cryptographic identity module. - Censorship-resistant naming module, defined by I5NS. - Secure session API. - Multiple-route module. - Integrity and mirroring module. - Adaptive transport module. - Ethical governance and transparency layer. 6. Conceptual API A conceptual API could expose: secure_session(identity, policy, content_type) Where identity identifies the source by public key or derived identifier; policy defines privacy, route, integrity and fallback requirements; and content_type describes the nature of the session. 7. Ethical Governance I5SL is not intended to protect crimes, violence, fraud, exploitation of vulnerable people or abuse of rights. However, responses to illicit acts SHOULD occur at the edges, through individualized investigation, due process, application-level moderation, trust signals, plural reputation lists, victim protection and accountability of authors. The protocol layer MUST NOT include a mandatory global censorship list, central political revocation authority, cryptographic backdoor or universal remote blocking mechanism. 8. Security Considerations Implementations should consider downgrade attacks, identity enumeration, traffic correlation, key compromise, malicious mirrors, hostile relays, denial of service, capture of reputation lists and state coercion against operators. 9. Privacy Considerations I5SL should minimize metadata collection and exposure. No component should unnecessarily combine civil identity, IP address, name query, intended destination and accessed content. 10. Legal Considerations I5SL should be analyzed in light of freedom of expression, privacy, data protection, due process, proportionality and human rights. State restriction orders should not be treated as automatically legitimate when they produce broad blocking, generalized weakening of encryption, punishment of innocent third parties or political censorship. 11. References RFC 2119, RFC 8174, RFC 8446, RFC 9000, RFC 8484, RFC 7858, RFC 9230, RFC 9849, RFC 7686, RFC 4033, IPFS documentation, Nostr specifications, UN documents on freedom of expression and #KeepItOn reports.