Independent technical-legal proposal
I5SL-DRAFT-01 — Internet 5.0 Session Layer
Session layer for availability, confidentiality, integrity, privacy and censorship resistance.
I5SL-DRAFT-01 — Internet 5.0 Session Layer
This is an independent draft, not an official IETF RFC.
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.