[MLS] Re: New Version Notification for draft-sullivan-mls-attachments-00.txt

[Nick Sullivan <[e-mail]>]

Hi Brendan,

This is the right question to ask. The signature part of this document
is under-specified and one of the trickier aspects of this
construction. What's the point of random-access encryption if you
don't have assurance that the entire attachment is signed, or you have
to decrypt or read the entire object to verify it, right? The answer
is a bit subtle because none of the AEADs specified in MLS are
key-committing, which makes SEAL's existing snapshot authenticator
insufficient for sender attribution.

The solution I'm writing up (it didn't land in raae-01) is to define a
snapshot authenticator that includes a hash of each ciphertext segment
as part of the existing metadata and a keyed KDF over this set. The
snapshot authenticator is signed by the sender, and the recipient
verifies it. Per-segment authenticity is guaranteed by the AEAD;
segment placement within the file and authorship are validated by the
metadata, and signature over the authenticator proves attribution.
There are fancier tree-based designs, but this flat derivation
provides sender authenticity for segments at the cost of sending one
hash per segment (essentially adding a key commitment to the AEAD).

The draft will need revision in any case because, as described,
ra-CMT-p (the position-commitment property defined in the raAE paper)
holds only under honest keys with a non-committing AEAD. A signed
digest transcript re-establishes the same position-commitment
guarantee under adversarially chosen or shared keys, grounded on
collision resistance rather than the AEAD's (absent) commitment
property. Key-comitting AEADs don't have this issue (cc: Andres in
case I'm wrong).

It should be simpler than it sounds. What do you think?

Best,
Nick

On Mon, Jul 6, 2026 at 11:25 PM Brendan McMillion
<[e-mail]> wrote:
>
> Hi Nick
>
> It's interesting that this doesn't authenticate the sender of the attachment, when that's typically the status quo for messages in MLS. Is signing all of the segments not a reasonable thing to do?
>
> Section 7.5 briefly mentions that I could sign the object or the reference. I'm not sure how signing the reference helps if the segments are still symmetrically encrypted.
>
> On Mon, Jul 6, 2026 at 4:20 PM Nick Sullivan <[e-mail]> wrote:
>>
>> Dear MLS,
>>
>> We've submitted a new individual draft,
>> draft-sullivan-mls-attachments-00, "Encrypted Attachments for MLS." It
>> specifies write-once, large encrypted attachments carried alongside an
>> MLS group. Content is encrypted under a key derived from the MLS
>> exporter and protected as a SEAL-attachment object, so a receiver can
>> decrypt and authenticate a byte range without processing the whole
>> file.
>>
>> https://datatracker.ietf.org/doc/draft-sullivan-mls-attachments/
>>
>> We'd welcome feedback, especially on:
>> - Is deriving the attachment key from the MLS exporter, in the SFrame
>> style, the right approach?
>> - Is the object_id model, including deterministic derivation, the right design?
>> - Is this a direction the working group would consider adopting?
>>
>> Test vectors under each MLS cipher suite will follow in -01.
>>
>> Best,
>> Nick (& Robert)
>>
>> On Mon, Jul 6, 2026 at 7:04 PM <[e-mail]> wrote:
>> >
>> > A new version of Internet-Draft draft-sullivan-mls-attachments-00.txt has been
>> > successfully submitted by Nick Sullivan and posted to the
>> > IETF repository.
>> >
>> > Name:     draft-sullivan-mls-attachments
>> > Revision: 00
>> > Title:    Encrypted Attachments for MLS
>> > Date:     2026-07-06
>> > Group:    Individual Submission
>> > Pages:    15
>> > URL:      https://www.ietf.org/archive/id/draft-sullivan-mls-attachments-00.txt
>> > Status:   https://datatracker.ietf.org/doc/draft-sullivan-mls-attachments/
>> > HTML:     https://www.ietf.org/archive/id/draft-sullivan-mls-attachments-00.html
>> > HTMLized: https://datatracker.ietf.org/doc/html/draft-sullivan-mls-attachments
>> >
>> >
>> > 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.
>> >
>> >
>> >
>> > The IETF Secretariat
>> >
>> >
>>
>> _______________________________________________
>> MLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]