Summary

  • The CURRENT BoF discussed using MLS key management with the TLS 1.3 record layer for long-lived two-party channels, but it is not chartered and IETF 126 minutes say the problem statement was not yet well understood.
  • In the current two-party draft, a peer that applies a commit sends an authenticated EpochKeyUpdate and may begin using the new material; the initiator must wait for that matching confirmation before making its pending state current.
  • A sent update, a locally installed key and a green encrypted channel do not alone prove shared epoch convergence, deletion of old secrets, closed compromise exposure or continued application service.

A truthful dashboard can still be one epoch early

Endpoint A sends a ConnectionUpdate. Endpoint B authenticates and applies the commit, sends EpochKeyUpdate, and starts using the new epoch. At that moment B has a truthful local record of transition. A is still in Awaiting EpochKeyUpdate. Until A receives and validates the confirmation under the state produced by its pending commit, it must not make that state current.

Nothing here is a defect. The asymmetry is the mechanism. It prevents a sender from treating its own proposal as proof that the peer received, authenticated and installed it. It also creates the operational interval most likely to disappear behind a single “key rotated” field.

The two-party profile is revision 01, dated 30 July 2026. The companion MLS-TLS draft is revision 01, dated 6 July. Both are individual Internet-Drafts with no RFC stream. The live CURRENT record still says BoF and “Not chartered yet.” The IETF 126 minutes go further: participants questioned the problem scope, the fit between a two-party protocol and several multi-party use cases, and whether existing TLS extensions already answer part of the need. This is work in progress, not an approved architecture.

Post-compromise security has a verb tense

RFC 9420 defines the stronger baseline carefully. An MLS Update proposal does not achieve post-compromise security until another member includes it in a Commit. More generally, PCS takes effect when members process the relevant Commit, not when its sender creates it. Forward secrecy also depends on deletion: old private keys and used message keys must stop existing where they could reconstruct earlier state.

The CURRENT drafts specialize that discipline for two parties and a TLS record layer. The proposed channel derives traffic secrets from the MLS exporter. In-band commits advance the key agreement; the record layer protects application data. The profile requires an authenticated epoch acknowledgement, and it defines what to do when updates cross, a connection breaks, or a pending commit must travel through resumption.

That still does not make “PCS enabled” a runtime receipt. Recovery from compromise assumes the adversary no longer controls the endpoint and cannot obtain the fresh material. It also assumes the relevant update reached the peer, was processed, and displaced secrets that are later deleted. A product label can name the property. Only the transition evidence can locate the channel in it.

Collision is not convergence

If both parties initiate an update, their commits can cross. The draft resolves the collision using the initial roles: one side can ignore the competing update while the other drops its pending commit and applies the peer's. The rule creates deterministic progress, but the two local histories are not identical.

Resumption adds another branch. A request may carry a pending commit. A receiver must recognize an identical commit it already applied and avoid applying it twice; in another case, a received commit can prove that a previously pending state was incorporated. Detecting that the connection was interrupted is outside the profile and depends on the transport.

An audit record that saves only the final epoch number loses the path. It cannot explain whether convergence came through an ordinary acknowledgement, collision resolution, retransmitted pending state or fresh resumption. That path matters when leaders ask how long old material remained usable, which side abandoned a proposal, or why application traffic paused.

The receipt set

Lu Heng's Minimum Initial Specification is useful here because the common protocol should define deterministic messages and state transitions without pretending to own every operational decision. Running-Code Primacy places actual endpoint state above a charter ambition or feature label. Reality-layer discipline then separates eight receipts: update created, commit sent, peer authenticated it, peer applied it, acknowledgement returned, initiator installed the epoch, old material deleted, and new-epoch application traffic independently accepted.

The draft itself shows why this caution is necessary. Its security analysis remains a TODO, as do parts of cross-protocol separation and message framing. A BoF can identify valuable work without conferring consensus. A proof of concept can test code without proving the complete composition. The honest product claim today is that CURRENT exposes an important transition problem and a candidate state machine for discussing it.

Sources and limits

These sources do not establish a chartered working group, IETF consensus, an adopted WG draft, an RFC, complete security analysis, interoperability, deployment, formal validation of the composition, measured compromise recovery, PQC deployment, incident or service result.