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

[Nick Sullivan <[e-mail]>]

On Thu, Jul 9, 2026 at 2:17 AM Brendan McMillion <[e-mail]>
wrote:

> Is non-repudiation important for MLS attachments in general? If not, the
>> design sketched out in the draft already provides ciphertext integrity.
>
>
> I would personally say it's important. It seems bad to say that if I send
> an attachment in a group, somebody else in the group can completely change
> its contents. Especially if the modified attachment could still look in the
> chat's UI like "I" sent it.
>

Agreed. Signatures are necessary for sender authentication within the group.


> 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.
>
>
> You're saying that the metadata will contain a list of the hashes of each
> segment? That would make the metadata pretty large. In fact, it seems
> pretty likely that your metadata would almost always be larger than your
> segment size. Going back to my original thought, it does seem better just
> to sign the individual segments. If the concern with signing each segment
> is that it would be too slow or that the signatures would be too large
> (something post-quantum), you could define (or more likely, leave it for a
> future document to define) a "signature" algorithm that's implemented as a
> Merkle tree or as a skip chain.
>

Or just a flat signed manifest in the case I’m describing.

The segments are 64KiB and the per-segment metadata is the AEAD tag (16
bytes for AES-GCM-128). The hashes are 32 bytes for SHA-256. You store one
per segment and front-load them before the ciphertext so they can be
fetched together. This adds around 0.05% to the length for multi-segment
attachments, or one new segment of metadata per 128MiB (check my
math). Then you combine them via a KDF, or if you’re fancy, a Merkle tree.
The higher-layer protocol can either sign every segment, or take advantage
of this shortcut and sign the KDF output, which is what I’m proposing.


> The skip chain "signature" idea seems more correct, since the encrypter
> can produce all of the signatures and ciphertexts in a single (reverse)
> pass over the attachment.
>

Of course, you’ll need all the hashes to validate the signature in a flat
or merkle scheme. Is the concern here around validating segments before the
entire object is encrypted, like you would see in streaming encryption? The
receiver won’t be able to validate any sections until the entire object’s
metadata is produced and read in this design, which could be an issue for
peeking into large files that haven’t been fully encrypted.

The skip chain idea is interesting because it can allow incremental
validation in the case of streamed objects that haven’t been fully
encrypted. The downside is that you fully lose the O(1) read random-access
property. That’s the main design point here, in my mind. Depending on
whether the attachment use case is streaming encryption or random-access,
different trade-offs apply and you have different optimal designs. The one
I went for here is focused on random-access, but if the streaming case is
more interesting, that’s also worth exploring.

Nick

>
> On Tue, Jul 7, 2026 at 6:40 AM Nick Sullivan <[e-mail]>
> wrote:
>
>> 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]
>>
>