Encrypted Attachments for MLS
draft-sullivan-mls-attachments-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Nick Sullivan , Raphael Robert | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sullivan-mls-attachments-00
Messaging Layer Security N. Sullivan
Internet-Draft Cryptography Consulting LLC
Intended status: Standards Track R. Robert
Expires: 7 January 2027 Phoenix R&D GmbH
6 July 2026
Encrypted Attachments for MLS
draft-sullivan-mls-attachments-00
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 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
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Messaging Layer
Security Working Group mailing list (mls@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/mls/.
Source for this draft and an issue tracker can be found at
https://github.com/grittygrease/draft-sullivan-mls-large-attachments.
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/.
Sullivan & Robert Expires 7 January 2027 [Page 1]
Internet-Draft MLS Attachments July 2026
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 7 January 2027.
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 . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Deriving the CEK . . . . . . . . . . . . . . . . . . . . 5
4.2. Choosing object_id . . . . . . . . . . . . . . . . . . . 6
4.3. Confidentiality Lifetime and Membership . . . . . . . . . 7
5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Object Layout . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Encrypting and Reading . . . . . . . . . . . . . . . . . 8
6. Referencing an Object . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. Confidentiality Lifetime and Membership . . . . . . . . . 10
7.2. Capacity and Limits . . . . . . . . . . . . . . . . . . . 11
7.3. Salt Uniqueness . . . . . . . . . . . . . . . . . . . . . 12
7.4. Constant-Time Comparison and Derivation . . . . . . . . . 12
7.5. Writer Attribution . . . . . . . . . . . . . . . . . . . 12
7.6. Operational Considerations . . . . . . . . . . . . . . . 13
8. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Sullivan & Robert Expires 7 January 2027 [Page 2]
Internet-Draft MLS Attachments July 2026
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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). SEAL is the random-access authenticated encryption
construction defined in [I-D.sullivan-cfrg-raae], 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
[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. This document introduces no new cryptographic primitive.
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 it carries its own salt-uniqueness
obligation (Section 7.3).
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 (Section 7).
Sullivan & Robert Expires 7 January 2027 [Page 3]
Internet-Draft MLS Attachments July 2026
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
SEAL-attachment object (SEAL Named Instantiations of
[I-D.sullivan-cfrg-raae]) in the linear layout (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 and the
object's plaintext length (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.
Sullivan & Robert Expires 7 January 2027 [Page 4]
Internet-Draft MLS Attachments July 2026
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). 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.
4. Key Derivation
This extension is a Safe Application component
([I-D.ietf-mls-extensions]) and is assigned a Component ID, a two-
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
Sullivan & Robert Expires 7 January 2027 [Page 5]
Internet-Draft MLS Attachments July 2026
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 chosen by the encryptor
(Section 4.2), passed to ExpandWithLabel as its raw octets with no
added length prefix or other framing. The KDFLabel structure of
[RFC9420] 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
([I-D.sullivan-cfrg-raae]). 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
([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
* 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
(Section 9).
Uniqueness is an honest-encryptor assumption: a member that controls
object_id also controls the CEK. The per-object salt (Section 5.1)
separates objects that share an object_id by accident, and not
reusing an object_id across epochs avoids cross-epoch linkage. These
Sullivan & Robert Expires 7 January 2027 [Page 6]
Internet-Draft MLS Attachments July 2026
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.
4.3. 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 (Section 5), since the group state that
would otherwise supply them may no longer be available. The
confidentiality-lifetime consequences of this persistent key are in
Section 7.
5. Parameters
An attachment is a SEAL-attachment(aead_id, kdf_id) object (SEAL
Named Instantiations of [I-D.sullivan-cfrg-raae]), where aead_id and
kdf_id are the IANA code points ([RFC5116], [RFC9180]) 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
(Section 4). Its capacity and security level are in Section 7.2.
5.1. Object Layout
The attachment object uses SEAL-attachment's linear layout in its
immutable form (Serialization Layouts of [I-D.sullivan-cfrg-raae]).
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:
+--------+--------+--------+- - -+--------+
| header | seg 0 | seg 1 | | seg i | ...
+--------+--------+--------+- - -+--------+
The header is the salt and the commitment:
Sullivan & Robert Expires 7 January 2027 [Page 7]
Internet-Draft MLS Attachments July 2026
header: +------+------------+
| salt | commitment |
+------+------------+
32 Nh octets
Under SEAL-attachment a segment is its ciphertext and a 16-octet tag,
with no stored nonce:
seg i: +----------------------+-------+
| ciphertext | tag |
+----------------------+-------+
segment_size 16 octets
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:
offset(i) = (32 + Nh) + i * (segment_size + 16)
To open the segments it fetches, a receiver uses SEAL's read
interface (Section 5.2). The epoch-key ladder and AEAD are inside
SEAL.
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.
On StartEnc and StartDec, the encryptor and the receiver supply the
object's object_id as G, SEAL's global associated data input
(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
the same way a wrong CEK does (Commitment of
[I-D.sullivan-cfrg-raae]). The object_id thus serves twice: as the
input that derives the CEK (Section 4) 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 (Derived Nonce Mode,
Segment AAD of [I-D.sullivan-cfrg-raae]) 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.
Sullivan & Robert Expires 7 January 2027 [Page 8]
Internet-Draft MLS Attachments July 2026
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 (Section 6) 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 (Section 7).
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 Section 6 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 (Section 6); or
* the object_id is empty.
Sullivan & Robert Expires 7 January 2027 [Page 9]
Internet-Draft MLS Attachments July 2026
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, from which
the receiver computes the segment count used by the whole-object
check and the range validation of Section 5.2.
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 ([I-D.ietf-mls-extensions]) 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.
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
Sullivan & Robert Expires 7 January 2027 [Page 10]
Internet-Draft MLS Attachments July 2026
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.
7.2. Capacity and Limits
An attachment inherits SEAL-attachment's capacity and security bounds
([I-D.sullivan-cfrg-raae]). For the three AEADs that MLS cipher
suites use:
+===================+=================+===========+
| MLS AEAD | Confidentiality | Integrity |
+===================+=================+===========+
| AES-128-GCM | 128-bit | 128-bit |
+-------------------+-----------------+-----------+
| AES-256-GCM | 256-bit | 128-bit |
+-------------------+-----------------+-----------+
| ChaCha20-Poly1305 | 256-bit | 128-bit |
+-------------------+-----------------+-----------+
Table 1: Per-suite security level for an
attachment (confidentiality is an upper bound)
The confidentiality column follows the AEAD key length, but it is an
upper bound. As Section 7.1 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
Sullivan & Robert Expires 7 January 2027 [Page 11]
Internet-Draft MLS Attachments July 2026
128 bits, for every suite. An object's maximum size and per-key
write budgets follow SEAL-attachment's analysis
([I-D.sullivan-cfrg-raae]). 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.
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 (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.
7.4. 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
([I-D.sullivan-cfrg-raae]). A variable-time commitment comparison
would leak the expected value one octet at a time to an adversary who
can retry tampered inputs.
7.5. 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 (Section 6) attributes it to
the sending member.
Sullivan & Robert Expires 7 January 2027 [Page 12]
Internet-Draft MLS Attachments July 2026
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 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 (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.
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 identifies this attachment encryption extension and is
used to domain-separate its uses of the MLS key schedule (Section 4).
Sullivan & Robert Expires 7 January 2027 [Page 13]
Internet-Draft MLS Attachments July 2026
* 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.
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-09, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
extensions-09>.
[I-D.sullivan-cfrg-raae]
Sullivan, N., "Random-Access Authenticated Encryption",
Work in Progress, Internet-Draft, draft-sullivan-cfrg-
raae-00, 25 March 2026,
<https://datatracker.ietf.org/doc/html/draft-sullivan-
cfrg-raae-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/rfc/rfc5116>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
Sullivan & Robert Expires 7 January 2027 [Page 14]
Internet-Draft MLS Attachments July 2026
[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, <https://www.rfc-editor.org/rfc/rfc9420>.
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,
<https://eprint.iacr.org/2025/2275>.
[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, <https://datatracker.ietf.org/doc/html/
draft-robert-mimi-attachments-06>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.
[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,
<https://www.rfc-editor.org/rfc/rfc9605>.
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 7 January 2027 [Page 15]