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

[Nick Sullivan <[e-mail]>]

Hi Soatok,

I'm glad to hear this is aligned with your interests. This design was
originally developed independently of FLOE, but proved sufficiently
similar as to share some of the security analysis. The construction is
slightly more general and introduces features such as per-segment ADs,
derived nonces, and the aforementioned snapshot authenticator. These
are all individual drafts, so feedback can be sent directly to the
authors for now. Looking forward to your feedback!

Best,
Nick

On Tue, Jul 7, 2026 at 4:58 AM Soatok Dreamseeker
<[e-mail]> wrote:
>
> Hi Brendan,
>
> Is non-repudiation important for MLS attachments in general? If not, the design sketched out in the draft already provides ciphertext integrity.
>
> I do agree that, if writer attribution / non-repudiation are actually important, the signing protocol should be spelled out a bit clearer (even if it's labeled as optional). However, I don't want to put the cart before the horse, so to speak.
>
> Should this property be important to the MLS ecosystem, signing a reference to an object and signing the object's ciphertext bytes must be unambiguous with some sort of injective encoding. Something like SequenceHash (in the order of: key0, value0, key1, value1, ...) with a domain-separation prefix between the two signature types would suffice. But we should be as clear about this as possible.
>
> Nick,
>
> The design, at first glance, reminded me of FLOE, and I was going to ask about that until I read the acknowledgements section. I generally like FLOE's design. I had previously suggested Random Access AEAD in a 2024 blog post of ideas I hadn't the time or energy to work on. Delighted to see that we were all thinking along similar lines.
>
> I plan to read over this draft carefully in the coming weeks. Is there a Git repository where the draft changes are being tracked? Happy to send pull requests if that's helpful.
>
> Looking forward to seeing this shape up!
>
> 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]
>>
>> _______________________________________________
>> MLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]