<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.24 (Ruby 3.4.1) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-mimi-msgid-aad-01" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->
  <front>
    <title abbrev="MIMI Message ID in AAD">Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data</title>
    <seriesInfo name="Internet-Draft" value="draft-mahy-mimi-msgid-aad-01"/>
    <author fullname="Rohan Mahy">
      <organization/>
      <address>
        <email>rohan.mahy@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="16"/>
    <area/>
    <workgroup>More Instant Messaging Interoperability</workgroup>
    <keyword>message ID</keyword>
    <keyword>AAD</keyword>
    <keyword>Additional Authenticated Data</keyword>
    <keyword>message ID component</keyword>
    <abstract>
      <?line 38?>

<t>The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent.
This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://rohanmahy.github.io/mimi-msgid-aad/draft-mahy-mimi-msgid-aad.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-mahy-mimi-msgid-aad/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        More Instant Messaging Interoperability  mailing list (<eref target="mailto:mimi@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mimi/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mimi/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/rohanmahy/mimi-msgid-aad"/>.</t>
    </note>
  </front>
  <middle>
    <?line 43?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Many messaging protocols and formats have a Message ID.
The MIMI content format defines how to calculate a MIMI Message ID (See <xref section="3.3" sectionFormat="of" target="I-D.ietf-mimi-content"/>) for an application/mimi-content application message.
A MIMI Message ID is currently only shared end-to-end encrypted with members of the MLS <xref target="RFC9420"/> group in which the message was sent.
This document defines an optional mechanism to share a Message ID in the
MLS AAD, so it is visible to intermediary providers.
This greatly facilitates debugging and troubleshooting, but causes a modest reduction in privacy.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="mechanism">
      <name>Mechanism</name>
      <t>This document defines a new Safe AAD <tt>message_id</tt> component as described in <xref section="4.9" sectionFormat="of" target="I-D.ietf-mls-extensions"/>.</t>
      <t>When the content of an MLS application message is a MIMI content message (media type <tt>application/mimi-content</tt>), if the <tt>message_id</tt> component is present inside <tt>SafeAAD.aad_items</tt>, it <bcp14>MUST</bcp14> contain the MIMI content Message ID calculated as described in <xref section="3.3" sectionFormat="of" target="I-D.ietf-mimi-content"/>.</t>
      <ul empty="true">
        <li>
          <t>To the extent that other application formats or media types have a Message ID, the Message ID for an application message of that type or format <bcp14>MAY</bcp14> be conveyed in this extension, using a message ID appropriate to the media type of the content.</t>
        </li>
      </ul>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>An attacker or provider with access to a fragment of message history, and the message logs of a MIMI provider in the path of a message could potentially learn more about the participants of a particular MIMI room or the room's corresponding MLS group if it can see message IDs.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="messageid-mls-component-type">
        <name>message_id MLS Component Type</name>
        <t>This document registers a new MLS Component Type in the Specification Required range with the following template:</t>
        <ul spacing="normal">
          <li>
            <t>Value: TBD (new assignment by IANA)</t>
          </li>
          <li>
            <t>Name: message_id</t>
          </li>
          <li>
            <t>Where: AD</t>
          </li>
          <li>
            <t>Recommended: Y</t>
          </li>
          <li>
            <t>Reference: RFC XXXX</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="I-D.ietf-mimi-content">
        <front>
          <title>More Instant Messaging Interoperability (MIMI) message content</title>
          <author fullname="Rohan Mahy" initials="R." surname="Mahy">
            <organization>Rohan Mahy Consulting Services</organization>
          </author>
          <date day="7" month="July" year="2025"/>
          <abstract>
            <t>   This document describes content semantics common in Instant Messaging
   (IM) systems and describes a profile suitable for instant messaging
   interoperability of messages end-to-end encrypted inside the MLS
   (Message Layer Security) Protocol.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-mimi-content-07"/>
      </reference>
      <reference anchor="RFC9420" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9420.xml">
        <front>
          <title>The Messaging Layer Security (MLS) Protocol</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes"/>
          <author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/>
          <author fullname="R. Robert" initials="R." surname="Robert"/>
          <author fullname="J. Millican" initials="J." surname="Millican"/>
          <author fullname="E. Omara" initials="E." surname="Omara"/>
          <author fullname="K. Cohn-Gordon" initials="K." surname="Cohn-Gordon"/>
          <date month="July" year="2023"/>
          <abstract>
            <t>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9420"/>
        <seriesInfo name="DOI" value="10.17487/RFC9420"/>
      </reference>
      <reference anchor="RFC2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="I-D.ietf-mls-extensions">
        <front>
          <title>The Messaging Layer Security (MLS) Extensions</title>
          <author fullname="Raphael Robert" initials="R." surname="Robert">
            <organization>Phoenix R&amp;D</organization>
          </author>
          <date day="21" month="July" year="2025"/>
          <abstract>
            <t>   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.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-mls-extensions-08"/>
      </reference>
    </references>
    <?line 105?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6VXbW/bNhD+zl/BKh+WDJHdtAHWGl1bN05RA3HSxem6Yhga
SqJtIhKpkZQ9L8h/2W/ZL9tzlOSXvG3F8iGmTne843PP3VFxHDOvfC57PDoy
ei6XSk+5n0k+MlbyoXZeaM9H0jkxpVdD7aU1pbQiUbnyy+YVVAdc6Q3FE7GU
lo9lWllS62eZ8spokfN+hf21V6nwMuMD4UXERJJYOUcQo+FoeGvPfn8QMVKe
GrvsQTIxjGUm1aJA2JkVEx8XYraMC1WouHBTlcVCZPHTA+aqpFDOwa9fllAe
Hl+853yHi9wZOFM6k6XEP+2jfR5JhGisEjk9DPvv8GMsVucX7yOmqyKRtscy
BNJjqdFOale5Hve2kgyhP2fCSoFdI7Yw9mpqTVXSgf4bjhG7kkvYZT3GY16s
AKAnABB+HoNw24qnpiiNhgqbS10hYM6/OSDOa9AiWhZC5VgSxG+V9JOOsVOS
C5vOIJ95X7pet0tqJFJz2WnVuiToJtYsnOzSBl0ynCo/qxKYWjMTmvLX3c4f
KeU4n/Mb+6+UO7V9R5lbZt0HCdGZ+SKPGBMAz1jCGR44n1R5XlMpOqfd+Qim
UXiF4IVWfwpCvRckssEhxNEhJ2+nJOoAcGytjS2gPQfgjHi6fmJxHHOROG9F
6hm7+IYK26Wa2ENK8QKa9a48kxOlpeOC3yqZfUp+UemGHEbnS+4NyEH8ddxM
6vJ+qFB3RyfjvZosVHyLmUpnwaJl10I4Du77Dg6hHEchVgXFtQ5oIYJHN0NB
UHxb1Rycn4wfZzPfBef3uDNceQ4nc+VUkkvaNZy2tGauMhynUwNbqCzLJWM7
hJ41WZXS1oyNhF42gdNRYeZNanIEqbMGSMdnYr4dZqdODzl6APSZWVAsqcjT
ijh6Nwt8dywlv74GrhQKf955TtA/GcaDUBg1N5vtb272yAOi4qIscwICNt1N
lc0XbSo6rH/HLcBCIi0skPaQ+5CGjKPNxd7E+MEytcuSsF6giO4wA8m5vn5y
/v7o5eGzpzc3/4sLmpuyyXIhU9SMcsWj3GCBG32w+L7kK6qNAn1a2OUmCYL3
KdovnXoiUiocah0IJKmmIfeUcVCjwk5uZoyHbJ8nlUcSKxdoW5gMzYYDrJo+
FFFp1VykS9AM3AoDUtOrmkADOmUgsasrGi2cUw936LKfxhc0RuiXn56F9fnx
T5+G58cDWo8/9E9OVgvWaIw/nH06GaxXa8ujs9Ho+HRQG0PKt0QsGvW/4A1F
FZ19vBienfZPohrSzbwQ6IAxkTWSpZXEAuEYTp5aleABNu+OPv7918Fhw4Jn
BwcvwYL64cXBD4d4WKBea2+BYvUjsrdkoKkUlnYReQ5sSyQid9AFUVA1ms+k
BXHZ978SMr/1+KskLQ8OXzcCOvCWsMVsSxgwuyu5Y1yDeI/oHjcrNLfkt5De
jrf/Zeu5xX1D+OpNjjrg8cGLN69Z4NCorQL2YPvUcsHHYiKpDPhlU2pfVXa5
nuoE51bK1o3msPPyVqPJXSz/QA+ha5C7uQH4n5GvUMdtc4EBDT6U3j1thmpQ
bLfD9s1uqMVwT+CXD7Wuy719rure8sBp4ABUdGGJMDMoEgA4fwdz+6vysnCX
+9QOAkdoX9GOks2wNrrJqjVnj2D1L00ZSL2+MMFNANBjiSFgILBbQLWTBC18
Dcg9g2V/Y/SGKO82/RW0oRvDW8AWas0EAumofNNwV6/PE0p8leF9XrnQ7zav
g3CAKwWutj7Uf93CV5lrGn9z7rrXre4DaHqUESuaPtdHuN6L9AoYIKy2Cdej
RKQpnJILwSdWTIuGXG0oiBQ37GXdOjYHSW6mYQCJ7fneXhhKgc3D69YgNVWe
8dJQxLixownl6DuAjy5VIjGVbwwt7hWqxBWr2b+WgBq2dmWNKeggpE3r7zBA
DQaoAzczApKqohmBE6JgioQ5KTfgdTVkw/5p/w5cOzt8zfmw19GK9hcA/3Yb
sHIKjGgc143grkWLybiUqZq0tDmXv1eK5rwVmgYzZYO0JibPzSJ81MmizMPH
C4v5zyLHVwG/eIeLCrkR+Eia6hBBsgwn2YPWabgWr+OH6DP17x7HF0kMn3TT
pO+nrMe/BMEEb3UKBcwK/gv+mptvAsIQRv30SptFLrNADceue/V3lcx+jCYY
FDK6ASJngzNQqdXEuPgHZ97tCacOAAA=

-->

</rfc>
