]>

rohan.ietf@gmail.com

MLS AAD additional authenticated data authenticated_data sage_aad This document specifies an explicit way to signal that the Additional Authenticated Data does include or should include data elements that are conveyed out-of-band (ex: are not in the MLS message). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The Messaging Layer Security (MLS) protocol includes message types with Additional Authenticated Data. defined new MLS Wire Formats for a similar purpose, however the Wire Format should be orthogonal to out-of-band AAD functionality.

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 when, and only when, they appear in all capitals, as shown here. Out-Of-Band AAD and In-Band AAD.

Mechanism ; uint64 epoch; ContentType content_type; SafeAADItem oob_aad; /* <== this is new */ opaque authenticated_data; /* usually just SafeAAD */ } PrivateContentAAD; struct { ProtocolVersion version = mls10; WireFormat wire_format; FramedContent content; /* can contain SafeAAD */ SafeAADItem oob_aad; /* <== this is new */ select (FramedContentTBS.content.sender.sender_type) { case member: case new_member_commit: GroupContext context; case external: case new_member_proposal: struct{}; }; } FramedContentTBS; ]]> Consists of:

• a oob-aad extension type. This specification cannot be a "safe" extension according to since it requires the MLS stack to modify its behavior outside of the concept of the specific components it also defines. The presence of the oob-aad extension type in the GroupContext means that all members of the group support the extensions and that if an out-of-band AAD component is signaled, the members of the room will include its actual value in Out-Of-Band AAD, without communicating it in the authenticated_data.
• an default-oob-aad-component component type. When present in the app_data_dictionary in the GroupContext, the out-of-band value of each signaled as-needed component is also included in the Out-Of-Band AAD.
• an as-needed-oob-aad-component component type.
  • When present in the app_data_dictionary in the GroupContext it enumerates OOB AAD that can be signaled on a per-message basis.
  • When present as a SafeAadItem in the aad_items list in the authenticated_content, the out-of-band value of each signaled as-needed component is also included in the Out-Of-Band AAD.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Phoenix R&D 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. Informative References Google Amazon Phoenix R&D Google This document describes an extension to support two new wire formats for MLS messages: PublicMessageWithoutAAD and PrivateMessageWithoutAAD.

Acknowledgments TODO acknowledge.