Ietf.org

Every encrypted connection you make today — whether it runs over TLS or QUIC — gets one security negotiation at the start. The keys agreed in that opening handshake protect the entire session. If an adversary captures the traffic and later obtains the key, everything in that session is retrospectively readable. It is a known structural gap in the internet's transport security model, one the engineering community has accepted for decades. An IETF working group proposal advanced at a Vienna meeting this week could change that.

On Tuesday evening at IETF 126, a Birds-of-a-Feather session called CURRENT — Continuous Updating and Ratcheting for Rekeying Encrypted Network Transport — held its first formal gathering and pushed to charter a new IETF Working Group. The goal: apply the key-management machinery of Messaging Layer Security (MLS) to general network transport, giving long-lived encrypted sessions the same continuous key renewal that already protects text messages on iOS and Android. This was confirmed in the IETF's official BoF session listing.

IETF 126 runs July 18–24 in Vienna. The CURRENT session was the first formal test of whether the engineering community believes the problem is real, the scope is tractable, and enough engineers are prepared to do the work.

What Continuous Key Ratcheting Actually Means

TLS 1.3 and QUIC both provide forward secrecy — but only in a limited sense. They negotiate session keys during the handshake, and a new session means new keys, so past sessions stay protected even if a future key is stolen. What they do not provide is post-compromise security within an ongoing session, a gap documented in the MLS Architecture standard (RFC 9750).

Post-compromise security is different from forward secrecy, and the difference matters. Forward secrecy means past sessions are protected against future key theft. Post-compromise security means that a compromised endpoint — a server that was briefly breached, a device that was temporarily controlled by an adversary — will, once it has been cleaned up, start producing keys that the adversary cannot predict. The session self-heals. TLS and QUIC do not do this within a session; MLS does, as defined in RFC 9750.

The consequence of this gap is greatest in long-lived connections: enterprise API sessions, VPN tunnels, IoT devices that phone home on a persistent channel, satellite links with intermittent connectivity. These connections hold session keys for extended periods without re-handshaking, and a key obtained by an adversary during that window continues to compromise traffic long after the moment of breach.

CURRENT's proposal is to use MLS's key management — specifically its asynchronous key updates, its cryptographic ratchet, and its formally verified security properties — as the foundation for a new two-party protocol at the transport layer, as outlined in the IETF 126 BoF session listing. The two-party focus is deliberately narrow. MLS was built for groups of two to thousands, but CURRENT targets the most common transport use case: one client, one server, a persistent encrypted channel between them.

Transport-Layer Security Gains Application-Layer Properties

The architectural significance of CURRENT goes beyond the specific properties it would add. Since TLS was first standardized in the 1990s, there has been a structural boundary between application-layer and transport-layer security: messaging applications could be designed with continuous key ratcheting (Signal, iMessage, and now RCS all do this), while transport protocols operated with a fundamentally different model — one negotiation at the start, then hold that key state for the session's duration.

CURRENT, if chartered and eventually standardized, would represent the first formal IETF effort to push application-layer security properties — forward secrecy and post-compromise security together — down to the transport layer. The two-party scope limitation is precisely what makes this tractable: group key consensus across thousands of participants introduces complexity that a two-party protocol avoids.

Already Proven at Hundreds of Millions of Devices

A central element of CURRENT's pitch is that its cryptographic foundation is not experimental. MLS was published as RFC 9420 in July 2023 after years of development, formal security analysis, and broad community review inside the IETF. It underwent verification using formal analysis tools — a level of scrutiny that most protocol proposals do not receive — giving CURRENT a stronger security baseline than most new IETF work can claim.

In March 2025, the GSM Association announced that RCS Universal Profile 3.0 would use MLS as its end-to-end encryption standard, as the IETF's announcement of the RCS MLS adoption confirms. By May 2026, Google Messages and Apple Messages had both begun the active MLS E2EE rollout to users, making RCS the first large-scale messaging service to support interoperable end-to-end encryption between different platform providers, per the Messaging Layer Security Wikipedia entry on the RCS rollout. MLS has also been deployed inside enterprise real-time platforms including Webex, Wire, and Discord for voice, video, and group messaging — giving the protocol a production track record across significantly different deployment environments, as the IETF's MLS adoption announcement documents.

The MLS implementations available today span five languages — Rust (OpenMLS, mls-rs), C++ (MLS++), TypeScript (MLS-TS), and more — from organizations including AWS Labs, Cisco, and the Matrix Foundation, per the Messaging Layer Security Wikipedia implementations table.

How Does an IETF Working Group Get Chartered?

For readers unfamiliar with IETF process: a Birds-of-a-Feather session is the formal first step in the path from an idea to a published RFC. Working-group-forming BoFs like CURRENT are designed to answer three questions — does the community agree the problem is real, is the scope narrow enough to be tractable, and are there enough engineers willing to do the work over the years a standard takes to complete?

If those questions get positive answers, the next step is a formal charter approved by the IETF's Internet Engineering Steering Group, followed by working group formation and the beginning of drafting actual protocol specifications. The IETF does not vote; it operates by rough consensus, assessed by session chairs and the IESG.

IETF 127, scheduled for November 14–20, 2026 in San Francisco at the Hilton Union Square, would be the next major milestone for CURRENT if the Vienna session proceeds favorably. Session recordings and notes from IETF 126 are being posted to the IETF Datatracker and IETF YouTube channel as the Vienna meeting concludes.

Why Post-Quantum Exposure Makes This Urgent Now

There is a second reason the security community cares about long-lived session keys beyond the conventional compromise scenario: harvest-now-decrypt-later attacks. Nation-state adversaries have been documented to collect encrypted traffic today and store it for future decryption once quantum computers capable of breaking classical key exchange become available.

Multiple national cybersecurity agencies — including NSA, CISA, and NIST — have confirmed that such collection is actively ongoing. Estimates from 2025–2026 research have revised the qubit requirements to break RSA-2048 downward from 20 million to fewer than 1 million, compressing timelines that once appeared comfortable.

Long-lived encrypted sessions — the very use case CURRENT targets — face heightened exposure under this threat model because they hold session key material for extended periods. An adversary who captures a long-lived enterprise API session today has a larger window of retrospectively decryptable content than an adversary who captures a short web request.

Because MLS already supports post-quantum cipher suites natively through the draft-ietf-mls-pq-ciphersuites specification, a CURRENT-derived protocol would not require a separate post-quantum retrofit. The upgrade path comes built into the foundation.

What Would Change if CURRENT Succeeds

The practical consequences of a successful CURRENT standard would be most significant in deployments where connections persist: enterprise environments that maintain long-lived TLS sessions to backend services, IoT deployments where devices hold persistent channels over days or weeks, VPN tunnels that stay open for the duration of a work session, and anywhere persistent connections substitute for repeated handshakes for performance or latency reasons.

For developers and architects in those environments, the operational difference would be this: today, a session key compromised partway through a long connection continues to expose all subsequent traffic in that session. Under a CURRENT-based protocol, the continuous ratchet ensures that keys age out rapidly and an adversary who holds one derived key cannot predict the next.

The work, if chartered, would likely take years. IETF Working Groups produce Internet-Drafts that circulate for review, comment, and revision through multiple rounds before a finished specification reaches the RFC Editor queue. The path from Vienna BoF to deployed RFC is a long one. But the combination of factors CURRENT brings — a formally verified base protocol, proven large-scale RCS deployment, native post-quantum support, and a deliberately limited two-party scope — gives the proposal an unusually strong foundation for new standards work.

Frequently Asked Questions

What specifically is missing from TLS and QUIC that CURRENT would add?

TLS 1.3 and QUIC provide forward secrecy by negotiating new session keys for each connection, so past sessions stay protected if a future key is stolen. What they do not provide is post-compromise security within a session: if an adversary gains access to an endpoint's session key material partway through a long connection, they can continue reading traffic until the session closes or a new handshake occurs. MLS's key ratcheting mechanism continuously derives new keys from old ones, discarding the old material, so that a compromised key quickly becomes useless. CURRENT proposes to standardize a two-party protocol that brings this continuous ratcheting to network transport connections.

Why use MLS specifically rather than building a new ratchet protocol from scratch?

MLS has two properties that make it the natural foundation. First, it has been formally verified using mathematical proof tools — a level of security assurance that most protocol proposals do not receive and that new custom designs would need to establish from scratch. Second, it has already been deployed at scale: Google Messages and Apple Messages rolled out MLS end-to-end encryption over RCS in May 2026, and Webex, Wire, and Discord use it in production. Using an already-standardized, already-deployed foundation gives CURRENT both a credibility argument for IETF chartering and a body of real-world implementation experience to draw on.

Does this proposal affect the devices and connections I use today?

Not immediately. CURRENT is in the earliest phase of IETF standardization — the community must first agree to charter a Working Group before any protocol drafting begins, and the path from charter to deployed RFC typically takes several years. For consumer web browsing, which uses short-lived TLS sessions, the proposal is largely irrelevant regardless. The security benefit applies specifically to long-lived connections: enterprise backend sessions, IoT device connections, VPN tunnels, and any persistent encrypted channel that maintains the same session keys for hours, days, or longer.

What does harvest-now-decrypt-later mean for long-lived sessions?

Nation-state adversaries and other well-resourced attackers have been documented to collect encrypted internet traffic today and store it for future decryption once quantum computers capable of breaking current key-exchange algorithms become available. Long-lived sessions — the use case CURRENT targets — are disproportionately exposed because they produce large volumes of ciphertext under the same session key material over extended periods. MLS's native support for post-quantum cipher suites means a CURRENT-derived transport protocol would address this exposure without requiring a separate post-quantum migration later.