]> Cryptography Consulting LLC

nicholas.sullivan+ietf@gmail.com

Phoenix R&D GmbH

ietf@raphaelrobert.com

Security Messaging Layer Security MLS attachments random-access encryption confidentiality lifetime 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 and length, and an optional locator) to fetch, key, and verify the object. 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. Discussion Venues Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (mls@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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 (): 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 () and its key from the MLS exporter (). SEAL is the random-access authenticated encryption construction defined in , and raAE is its scheme class. 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 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 () 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. This document introduces no new cryptographic primitive. It keys SEAL from the MLS exporter, following the pattern SFrame 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 it carries its own salt-uniqueness obligation (). This extension suits groups that need large, random-access, write-once attachments. 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, and revoking access to an existing attachment requires re-encryption ().

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 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 SEAL-attachment object ( of ) in the linear layout ().

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 (), unique within an MLS epoch, that names one attachment object and feeds its key derivation ().

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 and the object's plaintext length ().

Terms from MLS (), the MLS Safe Extension framework (), and SEAL () are used as defined there.

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.

The three planes of an attachment

The CEK never appears on the wire. Each side derives it from the exporter (). The bytes plane is a SEAL object that the application stores and transfers however it likes. The object reference lets a receiver locate the object. Because segments are at computable offsets, a receiver fetches and decrypts only the part it needs.

Key Derivation This extension is a Safe Application component () and is assigned a Component ID, a two-octet value, registered in . All of its uses of the MLS key schedule are domain-separated by that Component ID.

Deriving the CEK For each attachment object, the encryptor chooses an object_id and derives the content-encryption key: where:

component_secret:

the component's exported secret. SafeExportSecret is defined in of , and ComponentOperationLabel in of . SafeExportSecret derives from the MLS exporter, so the CEK is rooted in it.

object_id:

the per-object identifier chosen by the encryptor (), passed to ExpandWithLabel as its raw octets with no added length prefix or other framing. The KDFLabel structure of already carries object_id in a length-prefixed context field, so this document adds none of its own.

CEK:

the 32-octet content-encryption key. It is SEAL's input keying material and stands in for raAE key generation (). Segment confidentiality is bounded by the AEAD key length and the AEAD's own limits.

The group's MLS cipher suite is fixed for the group's lifetime (), so an attachment uses the same AEAD and KDF throughout.

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 (), which is virtually collision-free; and
• MUST NOT reuse an object_id across epochs.

An application that accepts linking an object to its sender MAY instead derive the object_id deterministically, provided the derivation still meets the requirements above. Combining the epoch, the leaf index, and a per-object counter, for example object_id = H(epoch, leaf_index, counter), keeps a sender's objects distinct within an epoch and across epochs while letting a receiver attribute each object to its sender. Note however that such an object_id embeds semantics by design: a party that sees it, such as storage or transport, can attribute an object to its sender and count that sender's objects in an epoch, a linkability the CSPRNG option avoids (). Uniqueness is an honest-encryptor assumption: a member that controls object_id also controls the CEK. The per-object salt () separates objects that share an object_id by accident, and not reusing an object_id across epochs avoids cross-epoch linkage. These uniqueness requirements bind the encryptor alone: a receiver cannot detect reuse of an object_id within an epoch or across epochs, so the unlinkability they provide rests on encryptor discipline, not on any receiver check.

Confidentiality Lifetime and Membership The component secret is derived from one MLS epoch's exporter. A member of that epoch can re-derive the CEK independently. A party that joins later, or any party after the epoch's secrets are deleted, cannot re-derive it: such a party either obtains the CEK by other means or is denied access. A holder that needs the attachment beyond its creation epoch retains the CEK, together with the cipher suite's AEAD and KDF identifiers (), since the group state that would otherwise supply them may no longer be available. The confidentiality-lifetime consequences of this persistent key are in .

Parameters An attachment is a SEAL-attachment(aead_id, kdf_id) object ( of ), where aead_id and kdf_id are the IANA code points (, ) of the group's MLS cipher suite's AEAD and KDF. SEAL-attachment is SEAL's named write-once instantiation: it fixes the immutable profile, a derived nonce, a segment size of 65536 octets (64 KiB), and the linear layout, leaving the cipher suite as the only choice. This document uses segment_size for that fixed 65536-octet value throughout. A receiver learns the cipher suite from the group state, so it is not carried in the reference. The object is keyed by the CEK (). Its capacity and security level are in .

Object Layout The attachment object uses SEAL-attachment's linear layout in its immutable form ( of ). The figures below are informative. The authoritative byte layout is SEAL's. Each expands one element of the one before it. Nh is the cipher suite's hash output length. An object is a header followed by its segments: The header is the salt and the commitment: Under SEAL-attachment a segment is its ciphertext and a 16-octet tag, with no stored nonce: Every non-final segment is exactly segment_size octets, so a segment sits at a computable offset and a receiver can seek to any segment without reading earlier ones. Only the final segment may be shorter: To open the segments it fetches, a receiver uses SEAL's read interface (). The epoch-key ladder and AEAD are inside SEAL.

Encrypting and Reading To encrypt, the encryptor derives the CEK, generates a fresh salt per the freshness requirement of , and runs SEAL encryption with the parameters of , writing the salt, commitment, and segments in the layout of . On StartEnc and StartDec, the encryptor and the receiver supply the object's object_id as G, SEAL's global associated data input ( of ). SEAL's commitment binds G, so a wrong or missing object_id fails the commitment check the same way a wrong CEK does ( of ). The object_id thus serves twice: as the input that derives the CEK () and as the committed G. Both EncSeg and DecSeg pass an empty per-segment associated data A_i. The nonce and the segment index and finality binding are as raAE specifies for derived-nonce mode and segment AAD (, of ) and are not restated here. 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) from the decryption state:

1. From segment_size, compute the indices i..j of the segments covering [a, b).
2. Fetch segments i..j only, not the whole object.
3. For each k in i..j, call DecSeg(state, k, segment k), which returns the plaintext or an error.

SEAL runs the key schedule and AEAD inside these calls. This document does not restate them. Opening a segment authenticates its contents, its index, and whether it is the final segment. Whole-object integrity follows from opening every segment: the receiver computes the segment count n from the length carried in the reference () and opens segments 0 through n-1 through SEAL, passing index n-1 as the final segment and the rest as non-final. A truncated, extended, reordered, or substituted object leaves a segment missing or makes an open fail, so SEAL's per-segment errors carry the whole-object check (). This check inherits the trustworthiness of the length it starts from, so it provides whole-object completeness only when the reference is authenticated to the group as describes. 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);
• 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 (); or
• the object_id is empty.

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 (). 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 () and cannot otherwise key the object. The reference MUST also carry the object's plaintext length, from which the receiver computes the segment count used by the whole-object check and the range validation of . For whole-object completeness and rollback resistance, the reference, including its length, and the ordering of successive references SHOULD be authenticated to the group. When the reference is carried in an MLS message, binding it into the message's authenticated data with the Safe AAD mechanism () authenticates the reference a receiver acts on to the group and the epoch. MLS does not, however, 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. An application that does not bind the reference forfeits whole-object completeness and rollback resistance. If the length is not authenticated, the loss is more than an unverified whole-object check: an adversary that lowers the length in the reference can present a truncated plaintext in which every segment the receiver opens authenticates, so the truncation is undetectable. Any locator or other fields the reference carries are the application's.

Security Considerations

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. This is a deliberate consequence of making the object persistent and random-access: a re-readable, seekable object needs a persistent key, which does not provide the per-message forward secrecy that MLS application messages have. 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.

Capacity and Limits An attachment inherits SEAL-attachment's capacity and security bounds (). For the three AEADs that MLS cipher suites use: Per-suite security level for an attachment (confidentiality is an upper bound)

MLS AEAD	Confidentiality	Integrity
AES-128-GCM	128-bit	128-bit
AES-256-GCM	256-bit	128-bit
ChaCha20-Poly1305	256-bit	128-bit

The confidentiality column follows the AEAD key length, but it is an upper bound. As notes, an attachment's confidentiality also rests on the group's key agreement, so a suite's figure holds only when that agreement is at least as strong, notably against a quantum adversary. Integrity is the 16-octet AEAD tag floor, about 128 bits, for every suite. An object's maximum size and per-key write budgets follow SEAL-attachment's analysis (). An application MUST stop writing an object before a per-key budget is exceeded. The CEK is fixed per object and cannot be rotated in place, so continued storage requires a new object under a fresh CEK.

Salt Uniqueness Unlike base SEAL, which keys each object with a fresh random CEK, this extension derives the CEK deterministically from (epoch, object_id) (). 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 (a non-MRAE AEAD) 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.

Constant-Time Comparison and Derivation The commitment comparison MUST be constant-time. The CEK and epoch-key derivations inherit SEAL's constant-time KDF requirement (). A variable-time commitment comparison would leak the expected value one octet at a time to an adversary who can retry tampered inputs.

Writer Attribution All epoch members can 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, and this extension does not attribute writes. An application that requires writer attribution, or whole-object authentication against a member, MUST sign the reference or the object with a per-member key. Binding the reference into an MLS message's authenticated data () attributes it to the sending member.

Operational Considerations Superseded objects are not deleted automatically: the profile is write-once and revocation re-encrypts to a new object (), 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.

Test Vectors An attachment object is a SEAL-attachment object and uses a derived nonce, so it stores no per-segment nonce (). 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.

Privacy Considerations An untrusted storage or transport observer 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 ( forbids that repetition). This unlinkability across objects and epochs rests on honest-encryptor discipline in choosing object_id (). It is not a property a receiver or observer can verify, since neither can detect a repeated or predictable object_id on its own. 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.

IANA Considerations This document requests one registration in the "MLS Component Types" registry established by . The component identifies this attachment encryption extension and is used to domain-separate its uses of the MLS key schedule ().

• Value: (assigned by IANA)
• Name: attachment_encryption
• Where: ES (an exported secret is used) and, when the reference is bound in an MLS message, AD (additional authenticated data)
• Recommended: Y
• Reference: This document

This document defines no new registries.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. Phoenix R&D The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. Cryptography Consulting LLC This document defines Random-Access Authenticated Encryption (raAE), a mechanism for encrypting segmented content that supports decryption of individual segments without processing others, selective re- encryption of individual segments in place, and content-level integrity via an accumulator binding all segment authentication tags. raAE is parameterized over an Authenticated Encryption with Associated Data (AEAD) algorithm, a key derivation function (KDF), segment size, epoch length, and nonce generation mode. raAE does not define wire formats, IANA registries, or key management; applications instantiate it with a chosen parameter set and protocol identifier. This document also defines "raAE-v1", a concrete profile with test vectors, supporting five AEAD algorithms: AES-256-GCM, ChaCha20-Poly1305, AES-256-GCM-SIV, AEGIS-256, and AEGIS-256X2, each with HKDF-SHA-256 and 65536-octet segments. Informative References This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (Selective Forwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. Phoenix R&D Phoenix R&D This document describes MIMI Attachments.

Acknowledgments This extension builds on the SEAL construction , the MLS Safe Extension framework , and the attachments transport . The random-access goals follow .