Add safe use of AAD to Safe Extensions framework (#29)

* Add safe use of AAD to Safe Extensions framework

* Explain negotiation of SafeAAD

* Add extension_aad ExtensionType

* Fix upload action (#35)

---------

Co-authored-by: Rohan Mahy <[email protected]>
Co-authored-by: raphaelrobert <[email protected]>

draft-ietf-mls-extensions.md

@@ -335,7 +335,8 @@ struct {
 The safe extension API allows extension designers to sign and encrypt payloads
 without the need to register their own IANA labels. Following the same pattern,
 this document also provides ways for extension designers to define their own
-wire formats, proposals and credentials.
+wire formats, proposals, credentials, and for structured data in the
+Additional Authenticated Data.
 
 #### Wire Formats
 
@@ -403,6 +404,42 @@ in question  with the extension_data containing all other relevant data. Note
 that any credential defined in this way has to meet the requirements detailed in
 Section 5.3 of the MLS specification.
 
+#### Additional Authenticated Data (AAD) {#safe-aad}
+
+The `PrivateContentAAD` struct in MLS can contain arbitrary additional
+application-specific AAD in its `authenticated_data` field. This framework
+defines a framing used to allow multiple extensions to add AAD safely
+without conflicts or ambiguity.
+
+When any AAD safe extension is included in the `authenticated_data` field,
+the "safe" AAD items MUST come before any non-safe data in the
+`authenticated_data` field. Safe AAD items are framed using the `SafeAAD`
+struct and are sorted in increasing numerical order of the `ExtensionType`
+as described below:
+
+~~~ tls
+struct {
+  ExtensionType extension_type;
+  opaque aad_item_data<V>;
+} SafeAADItem;
+
+struct {
+  SafeAADItem aad_items<V>;
+} SafeAAD;
+~~~
+
+If the `SafeAAD` is present or not is determined by the presence of the
+`extension_aad` GroupContext extension in the `required_capabilities` of the
+group. If `extension_aad` is present in `required_capabilities` but no
+"safe" AAD items are present, the `aad_items` is a zero-length vector.
+
+Each extension which include a `SafeAADItem` needs to advertise its
+`ExtensionType` in its LeafNode `capabilities.extensions`. Extensions MAY
+require an `ExtensionType` to be included in `required_capabilities`, but
+members which encounter a `SafeAADItem` they do not recognize can safely
+ignore it.
+
+
 ### Extension state: anchoring, storage and agreement
 
 The safe extension framework can help an MLS extension ensure that all group
@@ -480,6 +517,7 @@ management more costly than via extension-specific proposals, which can, for
 example, include only the data to be changed for a given GroupContext extension,
 or define semantics that allow modification based on local data only.
 
+
 ## Extension Design Guidance
 
 While extensions can modify the protocol flow of MLS and the associated
@@ -1170,6 +1208,19 @@ no additional data.
 * Recommended: Y
 * Reference: RFC XXXX
 
+### extension_aad MLS Extension
+
+The extension_aad MLS Extension Type is used to signal support for `SafeAAD`
+in LeafNode capabilities, and in GroupContext `required_capabilities`. It contains no additional data.
+
+* Value: 0x000B
+* Name: extension_aad
+* Message(s): LN,GC: This extension may appear in LeafNode and GroupContext
+  objects.
+* Recommended: Y
+* Reference: RFC XXXX
+
+
 ## MLS Proposal Types
 
 ### Extension Proposal
@@ -1236,6 +1287,16 @@ from a group more efficiently than using a `remove` proposal type, as the
 * Recommended: Y
 * Reference: RFC XXXX
 
+## MLS Extension Types
+
+This document modifies the rules of the "MLS Extension Types" registry
+to add a new Message type as follows:
+
+- AD: Authenticated Additional Data
+
+The `AD` Message type refers to an `ExtensionType` used inside the
+`SafeAADItem` structure defined in {{safe-aad}}.
+
 # Security considerations
 
 ## AppAck