[MLS] Re: I-D Action: draft-ietf-mls-extensions-10.txt

Raphael Robert <ietf@raphaelrobert.com> Mon, 06 July 2026 16:08 UTC

From: Raphael Robert <ietf@raphaelrobert.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Mon, 06 Jul 2026 17:50:22 +0200
References: <178335158037.323805.11583392092772418867@dt-datatracker-57b5d8f849-v5cht>
To: mls@ietf.org
In-Reply-To: <178335158037.323805.11583392092772418867@dt-datatracker-57b5d8f849-v5cht>
Message-Id: <5556BE2B-1A9E-4B53-B710-3986806ABDDC@raphaelrobert.com>
Message-ID-Hash: LQDWZMJBJFVXLTMHZUHGOKBGRSZD456I
Precedence: list
Subject: [MLS] Re: I-D Action: draft-ietf-mls-extensions-10.txt
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/vy27k_CEsvojkvqrBmwXUZI2-bo>

Hi all,

I just published a new version of mls-extensions. It addresses the feedback shared since the last draft and cleans up a few lose ends.

Here’s the full change log:

- remove AppAck ProposalType as it is now a Component conveyed in AppEphemeral
  Proposals
- be more pedantic when discussing that a proposal in required_capabilities
  implies all clients support it but not vice versa.
- correct location of GREASE values for advertising safe_add and
  app_components in LeafNodes; only allow GREASE in GI, LN, and KP.
- the app_components component is now mandatory to implement if
  app_data_dictionary is supported.
- the safe_add component is now mandatory to understand if
  app_data_dictionary is supported.
- rename MediaType.media_type to MediaType.type, and
  MediaTypeList.media_types to MediaTypeList.media_type_list
- clarify the behavior of an "empty" media type in application framing: if
  media_type.type is zero length.
- unsafe AAD is no longer allowed when the safe_aad component is present in
  the GroupContext
- rename "Safe Application API" to "Safe Application Interface"
- fix IANA registry names ("MLS Component Types", "MLS Extension Types") and
  restore missing registry section headers
- correct stale field and struct names in prose (component_data,
  app_data_dictionary, authenticated_data, required_wire_formats)
- reclassify last-resort KeyPackages as a KeyPackage component and fix various
  inconsistencies and typos

Raphael

> On 6. Jul 2026, at 17:26, internet-drafts@ietf.org wrote:
> 
> Internet-Draft draft-ietf-mls-extensions-10.txt is now available. It is a work
> item of the Messaging Layer Security (MLS) WG of the IETF.
> 
>   Title:   The Messaging Layer Security (MLS) Extensions
>   Author:  Raphael Robert
>   Name:    draft-ietf-mls-extensions-10.txt
>   Pages:   38
>   Dates:   2026-07-06
> 
> Abstract:
> 
>   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.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mls-extensions/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-mls-extensions-10.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-mls-extensions-10
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> MLS mailing list -- mls@ietf.org
> To unsubscribe send an email to mls-leave@ietf.org

[MLS] I-D Action: draft-ietf-mls-extensions-10.txt internet-drafts
[MLS] Re: I-D Action: draft-ietf-mls-extensions-1… Raphael Robert