Messaging Layer Security N. Sullivan Internet-Draft Cryptography Consulting LLC Intended status: Standards Track R. Robert Expires: 22 January 2027 Phoenix R&D GmbH 21 July 2026 Encrypted Attachments for MLS draft-sullivan-mls-attachments-01 Abstract This document defines random-access authenticated encryption of large write-once files for Messaging Layer Security (MLS) groups. A file is encrypted so that a receiver can decrypt and authenticate any byte range without processing the whole file. The encryption is SEAL- attachment, SEAL's named write-once attachment scheme (raAE), parameterized by the AEAD and key derivation function of the group's MLS cipher suite and keyed from the MLS exporter. The encrypted bytes are carried by any means, and a recipient needs only a small reference (the object's identifier, length, and snapshot value, and an optional locator) to fetch, key, and verify the object. Carrying that reference in an MLS message attributes the object to the member that sent the message. MLS application messages cannot carry large files, and existing attachment encryption produces an opaque, immutable blob with no partial access. This extension supplies the random-access layer those uses need. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 January 2027. Sullivan & Robert Expires 22 January 2027 [Page 1] Internet-Draft MLS Attachments July 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Deriving the CEK . . . . . . . . . . . . . . . . . . . . 5 4.2. Choosing object_id . . . . . . . . . . . . . . . . . . . 5 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Object Layout . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Encrypting and Reading . . . . . . . . . . . . . . . . . 7 6. Referencing an Object . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1. Confidentiality Lifetime and Membership . . . . . . . . . 10 7.2. Capacity and Limits . . . . . . . . . . . . . . . . . . . 10 7.3. Salt Uniqueness . . . . . . . . . . . . . . . . . . . . . 11 7.4. Writer Attribution . . . . . . . . . . . . . . . . . . . 11 7.5. Position Commitment under Adversarial Keys . . . . . . . 12 7.6. Operational Considerations . . . . . . . . . . . . . . . 12 8. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Sullivan & Robert Expires 22 January 2027 [Page 2] Internet-Draft MLS Attachments July 2026 1. Introduction This document defines an MLS extension for random-access authenticated encryption of large files. A file is encrypted with a random-access authenticated encryption (raAE) scheme ([I-D.sullivan-cfrg-raae]): it is split into fixed-size segments, each independently decryptable and authenticated, so a receiver can read any byte range at a cost proportional to the range rather than to the whole file. The scheme is SEAL-attachment, SEAL's named write-once attachment scheme, taking the AEAD and KDF of the group's MLS cipher suite (Section 5) and its key from the MLS exporter (Section 4). This fills a gap in MLS. An MLS application message protects its content with a single AEAD operation under a forward-secret ratchet key, so the content is all-or-nothing to decrypt and bounded by the AEAD's per-invocation input limit. Large files therefore cannot be sent as messages, and the existing attachment mechanism [I-D.robert-mimi-attachments] encrypts each file as a single opaque blob that is immutable and cannot be partially decrypted. The file bytes are an opaque object distributed by any means, and the members exchange only a small object reference (Section 6) that refers to it. This document specifies the object's encryption and keying. Upload, download, storage, and the in-band reference are left to the consuming application, for example the MIMI attachments mechanism. It keys SEAL from the MLS exporter, following the pattern SFrame [RFC9605] established for real-time media. Deriving the CEK deterministically from (epoch, object_id) is a new keying discipline for SEAL, not a new primitive, and carries its own salt-uniqueness obligation (Section 7.3). Its confidentiality is at the granularity of the creating epoch's membership, under a persistent key rather than the per-message forward secrecy of MLS application messages (Section 7). 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms. Attachment object: The encrypted representation of one attachment: a Sullivan & Robert Expires 22 January 2027 [Page 3] Internet-Draft MLS Attachments July 2026 SEAL-attachment object (SEAL Named Instantiations of [I-D.sullivan-seal-concrete]), whose byte layout is Section 5.1. Segment: A fixed-size unit of attachment plaintext. All segments except possibly the last contain exactly segment_size octets. object_id: An octet string of at most 255 octets (Section 4.2), unique within an MLS epoch, that names one attachment object and feeds its key derivation (Section 4). CEK: The content-encryption key (CEK) of an attachment object, derived from the MLS exporter and used as the input keying material of SEAL. Object reference: The application's in-band reference to an attachment object, carrying at least the object_id, the object's plaintext length, and the object's snapshot value (Section 6). Terms from MLS ([RFC9420]), the MLS Safe Extension framework ([I-D.ietf-mls-extensions]), and SEAL ([I-D.sullivan-cfrg-raae]) are used as defined there. 3. Architecture An attachment is handled on three independent planes: a key plane that derives the content key from the MLS exporter, an opaque bytes plane that holds the encrypted object, and a control plane that carries a small object reference among the members. key plane (this document) control plane (the application) MLS exporter object reference | (object_id, length, locator, ...) | derive (never on wire) | v | CEK ------- keys ------. | refers to | | v v .---------------------------------. bytes plane | encrypted SEAL object | | (opaque; see Object Layout) | '---------------------------------' stored and moved by any transport Figure 1: The three planes of an attachment The CEK never appears on the wire; each side derives it from the exporter (Section 4). Sullivan & Robert Expires 22 January 2027 [Page 4] Internet-Draft MLS Attachments July 2026 4. Key Derivation This extension is a Safe Application component ([I-D.ietf-mls-extensions]) and is assigned a Component ID, a four- octet value, registered in Section 10. All of its uses of the MLS key schedule are domain-separated by that Component ID. 4.1. Deriving the CEK For each attachment object, the encryptor chooses an object_id and derives the content-encryption key: component_secret = SafeExportSecret(ComponentID) CEK = ExpandWithLabel(component_secret, ComponentOperationLabel(ComponentID, "attachment"), object_id, 32) where: component_secret: the component's exported secret. SafeExportSecret is defined in Exported Secrets of [I-D.ietf-mls-extensions], and ComponentOperationLabel in Component IDs of [I-D.ietf-mls-extensions]. SafeExportSecret derives from the MLS exporter, so the CEK is rooted in it. object_id: the per-object identifier (Section 4.2), passed to ExpandWithLabel as raw octets; the KDFLabel structure of [RFC9420] already length-prefixes it, so this document adds no framing of its own. CEK: the 32-octet content-encryption key, SEAL's input keying material ([I-D.sullivan-cfrg-raae]). The group's MLS cipher suite is fixed for the group's lifetime ([RFC9420]), so an attachment uses the same AEAD and KDF throughout. 4.2. Choosing object_id An honest encryptor: * MUST choose a non-empty object_id of at most 255 octets, unique within the epoch; * SHOULD draw it from a cryptographically secure pseudorandom number generator (CSPRNG) with no embedded semantics, for example a version 4 UUID ([RFC9562]), which is virtually collision-free; and Sullivan & Robert Expires 22 January 2027 [Page 5] Internet-Draft MLS Attachments July 2026 * MUST NOT reuse an object_id across epochs. These uniqueness requirements bind the encryptor alone: a receiver cannot detect reuse of an object_id, so the unlinkability they provide rests on encryptor discipline, not on any receiver check (Section 9). An application MAY instead derive the object_id deterministically, provided the derivation still meets the requirements above. Deriving it from the epoch, the sender's leaf index, and a per-object counter, for example object_id = H(epoch, leaf_index, counter), makes non- collision between honest senders structural rather than probabilistic, since distinct leaf indices separate different senders' objects and a counter separates a sender's own. Such an object_id embeds semantics by design: a party that sees it can link a sender's objects within an epoch, a linkability the CSPRNG option avoids (Section 9). It does not attribute an object to its writer, which only the signature does (Section 7.4). 5. Parameters An attachment is a SEAL-attachment(aead_id, kdf_id) object (SEAL Named Instantiations of [I-D.sullivan-seal-concrete]), where aead_id and kdf_id are the IANA code points ([RFC5116], [RFC9180]) of the group's MLS cipher suite's AEAD and KDF. The name fixes every other parameter of the scheme, so the cipher suite is the only choice this document makes; the name fixes a segment size, written segment_size, of 65536 octets. A receiver learns the cipher suite from the group state, so it is not carried in the reference; a holder that keeps the object past its creating epoch retains the CEK and the cipher suite's AEAD and KDF identifiers, since the group state may no longer supply them. The object is keyed by the CEK (Section 4). Its capacity and security bounds are in Section 7.2. Every such object carries a snapshot value, and so does the reference to it (Section 6). A receiver checks one segment against the snapshot without reading the others (Section 5.2). 5.1. Object Layout The attachment object uses SEAL-attachment's aligned layout, which fixes the object's byte layout and its offset arithmetic (Aligned Layout of [I-D.sullivan-seal-concrete]). That layout leaves two details to the consuming protocol, and a receiver cannot compute a segment's offset until both are settled. This document settles them: * There is no prefix. An object begins with SEAL's header at offset 0. Sullivan & Robert Expires 22 January 2027 [Page 6] Internet-Draft MLS Attachments July 2026 * The slot between the header and the first segment boundary is zero-padded, so every ciphertext segment except the last is a full segment_size octets. A receiver then derives every offset from the object's length and the group's cipher suite, with no further input: the length gives the segment count, the segment count and the cipher suite's hash length give the header's size, and the first segment begins at the next segment_size boundary after it. Checking one segment takes three reads: the per-epoch digests, which a receiver reads once and caches; the metadata entries of that segment's own epoch; and the segment itself. object each read +--------------+ | 96 B | +--------------+ | digests | 64 KiB ----> +----------+ +--------------+ | 64 KiB | all | | +----------+ | metadata | | 2048 epochs | 96 MiB ----> +----------+ | | | 48 KiB | 1 epoch | | +----------+ +--------------+ | | | segments | | 2M segments | 128 GiB ----> +----------+ | | | 64 KiB | 1 segment | | +----------+ | | +~~~~~~~~~~~~~~+ 176 KiB Figure 2: Three reads check any segment of a 128 GiB object (SHA-256) The entries are grouped by epoch, which is what bounds the second read: an epoch's 1024 entries are adjacent, so one read returns all of them. An epoch's digest is 32 octets, so 2048 of them fill one read, which is the 128 GiB above. 5.2. Encrypting and Reading To encrypt, the encryptor derives the CEK, generates a fresh salt per the freshness requirement of Section 7.3, and runs SEAL encryption with the parameters of Section 5, writing the salt, commitment, and segments in the layout of Section 5.1. Sullivan & Robert Expires 22 January 2027 [Page 7] Internet-Draft MLS Attachments July 2026 On StartEnc and StartDec, both sides supply the object_id as G, SEAL's global associated data (Per-Message Inputs of [I-D.sullivan-cfrg-raae]). SEAL's commitment binds G, so a wrong or missing object_id fails the commitment check as a wrong CEK does. The object_id thus serves twice: it derives the CEK (Section 4) and is the committed G. A receiver opens an object in two phases: it initializes once, then reads ranges, and it needs the header only for the first phase. To initialize, the receiver derives the CEK, fetches the header (the salt and commitment), and calls StartDec to obtain the decryption state. StartDec checks the commitment, rejecting a wrong key before any segment is read. The receiver retains the state and does not need the header again. To read octet range [a, b), the receiver fetches the segments that cover it, at offsets the layout fixes (Section 5.1), and opens each with DecSeg, which runs the key schedule and AEAD inside. Opening a segment authenticates it only to the group, since every member holds the CEK (Section 7.4); whole-object integrity comes from the snapshot the reference carries (Section 6). A receiver checks a segment against that snapshot by SEAL's random- access verification, which is not restated here (Epoch Digest Tree of [I-D.sullivan-seal-concrete]). One input to that check differs here. The value a receiver compares against MUST be the snapshot the reference carries, and a receiver MUST NOT substitute the copy stored in the object. SEAL compares against the stored copy, which suffices where each object has a fresh random CEK. Here every member derives the CEK and can compute a stored copy that matches any object it writes, so the stored copy attributes nothing. Only the value the group authenticated does. This check is only as strong as the snapshot it starts from, so it gives whole-object completeness and attribution only when the reference is authenticated to the group (Section 6). A valid attachment object has at least one segment. A receiver MUST reject the object when: * StartDec rejects the header (a wrong key or parameter set); * SEAL's verification fails against the snapshot the reference carries; Sullivan & Robert Expires 22 January 2027 [Page 8] Internet-Draft MLS Attachments July 2026 * DecSeg rejects a segment it opens (the contents, index, or finality fail to authenticate); * a segment it needs is absent (the object is shorter than the reference's length implies); * a requested byte range lies beyond the length carried in the reference (Section 6); or * the object_id is empty. 6. Referencing an Object A consuming application refers to an attachment object with a small reference. This document does not define the reference's structure or its transport. Those are the application's, for example the MIMI attachments mechanism ([I-D.robert-mimi-attachments]). This section states only what the reference MUST convey for this extension's guarantees to hold. The reference MUST carry the object_id, because a receiver derives the CEK from it (Section 4) and cannot otherwise key the object. The reference MUST also carry the object's plaintext length, which the receiver needs to locate segments in the layout (Section 5.1) and to validate a requested range. The reference MUST also carry the object's snapshot value, against which the receiver checks every segment it reads (Section 5.2). Writer attribution and whole-object completeness need the reference authenticated to the group. For that, it MUST be bound into an MLS message's authenticated data, which the sender's signature covers: the signature authenticates the reference and attributes the object to the sending member (Section 7.4). This document defines no signature of its own. The length needs that authentication because the snapshot binds only the segment count: an adversary can understate the length within the final segment's span without changing the count, and a receiver that never fetches the final segment cannot detect the truncation. MLS does not give a total order across different senders' application messages within an epoch, so delivery order alone does not establish which object is current. An application that needs a current-object notion MUST scope the ordering to a single sender or carry an explicit application-level sequence number in the authenticated reference. Sullivan & Robert Expires 22 January 2027 [Page 9] Internet-Draft MLS Attachments July 2026 Any locator or other fields the reference carries are the application's. 7. Security Considerations 7.1. Confidentiality Lifetime and Membership The CEK is derived from one MLS epoch's exporter and, unlike an MLS message key, is not deleted after use: it is a persistent key for the life of the attachment. The MLS exporter itself is forward-secure across epochs, so once that epoch's secrets are deleted the CEK cannot be re-derived from MLS. Holders that retain the CEK keep access and others do not. Attachment confidentiality is therefore at the granularity of the creating epoch's membership and lasts as long as any holder retains the CEK, not at the per-message granularity of MLS application messages. A re-readable, seekable object needs a persistent key, so it cannot have the per-message forward secrecy of MLS application messages. Removing a member does not by itself revoke access to attachments created while they were present, since they may have retained the CEK. An application that must revoke access to an existing attachment MUST distribute a new object encrypted under a CEK derived in a later epoch. This costs the size of the attachment, because the removed member knows the old CEK. Because the AEAD and KDF are inherited from the MLS cipher suite, an attachment inherits the cipher suite's AEAD and KDF strength. The CEK is exported from the MLS key schedule, so an attachment's long- term confidentiality rests on the group's key agreement, not on the AEAD key size alone. A quantum adversary that records a group's handshake can, once a quantum computer is available, recover the exported secrets of past epochs, and thus the CEK, regardless of the AEAD key size. Deployments that need long-lived confidentiality for attachments SHOULD therefore run a post-quantum MLS cipher suite. A larger symmetric key does not address this threat. 7.2. Capacity and Limits An attachment inherits SEAL-attachment's capacity and security bounds ([I-D.sullivan-cfrg-raae]), which rest on the group's key agreement as well as the AEAD (Section 7.1). An application MUST stop writing an object before a per-key budget is exceeded. The CEK is fixed per object, so continued storage requires a new object under a fresh CEK. The per-segment metadata adds one hash per segment, so both an attachment's storage overhead and its per-segment read cost scale with the cipher suite's hash length ([I-D.sullivan-cfrg-raae]). Sullivan & Robert Expires 22 January 2027 [Page 10] Internet-Draft MLS Attachments July 2026 SEAL-attachment pins the epoch length for every suite, so the SHA-512 suites, whose entries are largest, cost one extra metadata read per segment checked. 7.3. Salt Uniqueness Unlike base SEAL, which keys each object with a fresh random CEK, this extension derives the CEK deterministically from (epoch, object_id) (Section 4). SEAL-attachment uses a derived nonce, so the per-object salt is the only value that separates two encryptions under the same CEK. Reusing an (object_id, salt) pair within an epoch reuses the derived nonces, which for an AEAD that is not misuse-resistant, such as AES-GCM or ChaCha20-Poly1305, is a two-time pad and breaks confidentiality. The encryptor therefore MUST generate a fresh, uniformly random 32-octet salt from a CSPRNG for each object, and MUST NOT re-encrypt an object under a previously used (object_id, salt) pair, including after a crash or retry. 7.4. Writer Attribution All epoch members derive the CEK, so per-segment authentication binds an attachment to the group, not to a writer: any member can produce a segment that others accept. Attribution comes from the sender's signature. The reference carries the object's snapshot value, and MLS covers a message's authenticated data by the sender's signature, so binding the reference into an MLS message attributes the object to the sending member (Section 6). A receiver checks one segment against the snapshot and attributes it without reading the rest (Section 5.2). The snapshot binds each segment's ciphertext by a collision-resistant digest, so a signature over it attributes content even against a member that holds the CEK (Epoch Digest Tree of [I-D.sullivan-seal-concrete]). Attribution is to the member that sent the reference, in the epoch it was sent, and nothing re-attests the object afterward. MLS gives no total order across senders within an epoch, so an application that needs the original writer MUST make that writer the object's only sender, and one that needs a current-object notion MUST carry the ordering itself (Section 6). Sullivan & Robert Expires 22 January 2027 [Page 11] Internet-Draft MLS Attachments July 2026 7.5. Position Commitment under Adversarial Keys No AEAD an MLS cipher suite uses is key-committing, so SEAL's commitment does not bind a segment's position: without the snapshot, a member that controls the CEK could open one ciphertext segment at two positions (Commitment Security of [I-D.sullivan-cfrg-raae]). An authenticated snapshot pins each segment's ciphertext to its index by collision resistance, so no CEK holder can move a segment, which restores ra-CMT-p against adversarially chosen keys (Epoch Digest Tree of [I-D.sullivan-seal-concrete]). It holds only for a snapshot the group authenticates. 7.6. Operational Considerations Superseded objects are not deleted automatically: the profile is write-once and revocation re-encrypts to a new object (Section 7.1), so the application owns garbage collection and any link from a replacement to its predecessor. Revocation cost scales with the total volume of attachments the removed member could read, not with one object. Recovering from corruption means fetching the object again, since there is no in-place repair. 8. Test Vectors An attachment object is a SEAL-attachment object and uses a derived nonce, so it stores no per-segment nonce (Section 5). SEAL's published example vectors use a random nonce and a different layout, so they do not apply byte for byte. Its derived-nonce example vector is the closest format reference but is computed for AES-256-GCM-SIV. Test vectors specific to SEAL-attachment under each MLS cipher suite are TBD, and this document defines none of its own. 9. Privacy Considerations An untrusted observer of the object's storage or transport does not learn the plaintext, but it does learn metadata about the object. It learns the exact plaintext length, which is recoverable from the object byte count regardless of the reference. It learns which byte ranges each reader fetches, an access-pattern channel. It can link fetches by object_id or locator, including across epochs if an object_id were to repeat (Section 4 forbids that repetition). This unlinkability across objects and epochs rests on honest-encryptor discipline in choosing object_id (Section 4.2). It is not a property a receiver or observer can verify, since neither can detect a repeated or predictable object_id on its own. Sullivan & Robert Expires 22 January 2027 [Page 12] Internet-Draft MLS Attachments July 2026 The reference also carries the object's snapshot value (Section 6), which discloses nothing further: it is a keyed value, pseudorandom without the CEK. These metadata exposures are by design and out of scope for the encryption layer. Length-hiding by padding and access-pattern hiding by full-object fetch or oblivious access are left to the application and the transport. Transport-level sender metadata, such as the connection and timing of a fetch, is likewise out of scope for this document. 10. IANA Considerations This document requests one registration in the "MLS Component Types" registry established by [I-D.ietf-mls-extensions]. The component domain-separates this extension's uses of the MLS key schedule (Section 4), which is its only use of an MLS facility. * Value: (assigned by IANA) * Name: attachment_encryption * Where: ES (an exported secret is used) * Recommended: Y * Reference: This document This document defines no new registries. 11. References 11.1. Normative References [I-D.ietf-mls-extensions] Robert, R., "The Messaging Layer Security (MLS) Extensions", Work in Progress, Internet-Draft, draft-ietf- mls-extensions-10, 6 July 2026, . [I-D.sullivan-cfrg-raae] Sullivan, N., "Random-Access Authenticated Encryption", Work in Progress, Internet-Draft, draft-sullivan-cfrg- raae-02, 13 July 2026, . Sullivan & Robert Expires 22 January 2027 [Page 13] Internet-Draft MLS Attachments July 2026 [I-D.sullivan-seal-concrete] Sullivan, N., "SEAL Cipher Suites and Instantiations", Work in Progress, Internet-Draft, draft-sullivan-seal- concrete-00, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, . [RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, . 11.2. Informative References [FLOE] Fabrega, A., Len, J., Ristenpart, T., and G. Rubin, "Random-Access AEAD for Fast Lightweight Online Encryption", IACR ePrint 2025/2275, 2025, . [I-D.robert-mimi-attachments] Robert, R. and K. Kohbrok, "MIMI Attachments", Work in Progress, Internet-Draft, draft-robert-mimi-attachments- 06, 29 June 2026, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . Sullivan & Robert Expires 22 January 2027 [Page 14] Internet-Draft MLS Attachments July 2026 [RFC9605] Omara, E., Uberti, J., Murillo, S. G., Barnes, R., Ed., and Y. Fablet, "Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media", RFC 9605, DOI 10.17487/RFC9605, August 2024, . Acknowledgments This extension builds on the SEAL construction [I-D.sullivan-cfrg-raae], the MLS Safe Extension framework [I-D.ietf-mls-extensions], and the attachments transport [I-D.robert-mimi-attachments]. The random-access goals follow [FLOE]. Authors' Addresses Nick Sullivan Cryptography Consulting LLC Email: nicholas.sullivan+ietf@gmail.com Raphael Robert Phoenix R&D GmbH Email: ietf@raphaelrobert.com Sullivan & Robert Expires 22 January 2027 [Page 15]