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.