Script updating gh-pages from 24eaee7. [ci skip]

draft-ietf-mls-architecture.html

@@ -1045,11 +1045,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">MLS Architecture</td>
-<td class="right">July 2024</td>
+<td class="right">August 2024</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Beurdouche, et al.</td>
-<td class="center">Expires 9 January 2025</td>
+<td class="center">Expires 4 February 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1062,12 +1062,12 @@
 <dd class="internet-draft">draft-ietf-mls-architecture-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-07-08" class="published">8 July 2024</time>
+<time datetime="2024-08-03" class="published">3 August 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Informational</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2025-01-09">9 January 2025</time></dd>
+<dd class="expires"><time datetime="2025-02-04">4 February 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1076,7 +1076,7 @@
 </div>
 <div class="author">
       <div class="author-name">E. Rescorla</div>
-<div class="org">Windy Hill Systems, LLC</div>
+<div class="org">Independent</div>
 </div>
 <div class="author">
       <div class="author-name">E. Omara</div>
@@ -1143,7 +1143,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 9 January 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 4 February 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1234,6 +1234,9 @@ <h2 id="name-copyright-notice">
                     <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="auto internal xref">5.2.3</a>.  <a href="#name-welcome-messages" class="internal xref">Welcome Messages</a></p>
 </li>
                 </ul>
+</li>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
+                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="auto internal xref">5.3</a>.  <a href="#name-invalid-commits" class="internal xref">Invalid Commits</a></p>
 </li>
             </ul>
 </li>
@@ -2138,30 +2141,15 @@ <h4 id="name-strongly-consistent">
 same time.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.1-2">As an example, there could be an "ordering server" Delivery Service that
 broadcasts all messages received to all users and ensures that all clients see
-handshake messages in the same order. Clients that send a Commit would then wait
-to apply it until it's broadcast back to them by the Delivery Service, assuming
-they don't receive another Commit first.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
-<p id="section-5.2.1-3">The Delivery Service can rely on the <code>epoch</code> and <code>content_type</code> fields of an
-MLSMessage for providing an order only to handshake messages, and possibly even
-filter or reject redundant Commit messages proactively to prevent them from
-being broadcast. Alternatively, the Delivery Service could simply apply an order
-to all messages and rely on clients to ignore redundant Commits.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
-<p id="section-5.2.1-4">There is some risk associated with filtering.  Situations can arise where a
-malicious or buggy client sends a Commit that is not accepted by some members of
-the group, and the DS is not able to detect this and reject the Commit.  For
-example, a buggy client might send a encrypted Commit with an invalid set of
-proposals.  Or a malicious client might send a malformed Commit of the form
-described in <span><a href="https://rfc-editor.org/rfc/rfc9420#section-16.12" class="relref">Section 16.12</a> of [<a href="#RFC9420" class="cite xref">RFC9420</a>]</span>.<a href="#section-5.2.1-4" class="pilcrow">¶</a></p>
-<p id="section-5.2.1-5">In such situations, the DS might update its internal state under the assumption
-that the Commit has succeeded and thus end up in a state inconsistent with the
-members of the group.  For example, the DS might think that the current epoch is
-now <code>n+1</code> and reject any commits from other epochs, while the members think the
-epoch is <code>n</code>, and as a result, the group is stuck -- no member can send a Commit
-that the DS will accept.<a href="#section-5.2.1-5" class="pilcrow">¶</a></p>
-<p id="section-5.2.1-6">Given these risks, it is effectively impossible for a strongly consistent DS to
-know with absolute certainty when it is safe to update its internal state.  It
-is up to the designers and operators of a DS to ensure that sufficient
-mechanisms are in place to address these risks.<a href="#section-5.2.1-6" class="pilcrow">¶</a></p>
+messages in the same order. This would allow clients to only apply the first
+valid Commit for an epoch and ignore subsequent ones. Clients that send a Commit
+would then wait to apply it until it is broadcast back to them by the Delivery
+Service, assuming they do not receive another Commit first.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-3">Alternatively, the Delivery Service can rely on the <code>epoch</code> and <code>content_type</code>
+fields of an MLSMessage to provide an order only to handshake messages, and
+possibly even filter or reject redundant Commit messages proactively to prevent
+them from being broadcast. There is some risk associated with filtering, which
+is discussed further in <a href="#invalid-commits" class="auto internal xref">Section 5.3</a>.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="eventually-consistent">
@@ -2234,6 +2222,50 @@ <h4 id="name-welcome-messages">
 </div>
 </section>
 </div>
+<div id="invalid-commits">
+<section id="section-5.3">
+        <h3 id="name-invalid-commits">
+<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-invalid-commits" class="section-name selfRef">Invalid Commits</a>
+        </h3>
+<p id="section-5.3-1">Situations can arise where a malicious or buggy client sends a Commit that is
+not accepted by all members of the group, and the DS is not able to detect this
+and reject the Commit.  For example, a buggy client might send an encrypted
+Commit with an invalid set of proposals, or a malicious client might send a
+malformed Commit of the form described in <span><a href="https://rfc-editor.org/rfc/rfc9420#section-16.12" class="relref">Section 16.12</a> of [<a href="#RFC9420" class="cite xref">RFC9420</a>]</span>.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
+<p id="section-5.3-2">In situations where the DS is attempting to filter redundant Commits, the DS
+might update its internal state under the assumption that a Commit has succeeded
+and thus end up in a state inconsistent with the members of the group.  For
+example, the DS might think that the current epoch is now <code>n+1</code> and reject any
+commits from other epochs, while the members think the epoch is <code>n</code>, and as a
+result, the group is stuck -- no member can send a Commit that the DS will
+accept.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
+<p id="section-5.3-3">Such “desynchronization” problems can arise even when the Delivery Service takes
+no stance on which Commit is "correct" for an epoch. The DS can enable clients
+to choose between Commits, for example by providing Commits in the order
+received and allow clients to reject any Commits that
+violate their view of the group's policies. As such, all honest and
+correctly-implemented clients will arrive at the same "first valid Commit" and
+choose to process it. Malicious or buggy clients that process a different Commit
+will end up in a forked view of the group.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
+<p id="section-5.3-4">When these desynchronizations happen, the application may choose to take action
+to restore the functionality of the group.  These actions themselves can have
+security implications.  For example, a client developer might have a client
+automatically rejoin a group, using an external join, when it processes an
+invalid Commit.  In this operation, however, the client trusts that the
+GroupInfo provided by the DS faithfully represents the state of the group, and
+not, say, an earlier state containing a compromised leaf node. In addition, the
+DS may be able to trigger this condition by deliberately sending the victim an
+invalid Commit. In certain scenarios, this trust can enable the DS or a
+malicious insider to undermine the post-compromise security guarantees provided
+by MLS.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
+<p id="section-5.3-5">Actions to recover from desynchronization can also have availability and DoS
+implications.  For example, if a recovery mechanism relies on external joins, a
+malicious member that deliberately posts an invalid Commit could also post a
+corrupted GroupInfo object in order to prevent victims from rejoining the group.
+Thus, careful analysis of security implications should be made for any system
+for recovering from desynchronization.<a href="#section-5.3-5" class="pilcrow">¶</a></p>
+</section>
+</div>
 </section>
 </div>
 <div id="functional-requirements">
@@ -2971,12 +3003,13 @@ <h4 id="name-forward-and-post-compromise">
 <p id="section-8.2.2-1">MLS provides additional protection regarding secrecy of past messages and future
 messages. These cryptographic security properties are Forward Secrecy (FS) and
 Post-Compromise Security (PCS).<a href="#section-8.2.2-1" class="pilcrow">¶</a></p>
-<p id="section-8.2.2-2">FS means that access to all encrypted traffic history combined with access to
-all current keying material on clients will not defeat the secrecy properties of
-messages older than the oldest key of the compromised client.  Note that this
-means that clients have the extremely important role of deleting appropriate
-keys as soon as they have been used with the expected message, otherwise the
-secrecy of the messages and the security for MLS is considerably weakened.<a href="#section-8.2.2-2" class="pilcrow">¶</a></p>
+<p id="section-8.2.2-2">FS means that access to all encrypted traffic history combined with
+access to all current keying material on clients will not defeat the
+secrecy properties of messages older than the oldest key of the
+compromised client.  Note that this means that clients have to delete the appropriate
+keys as soon as they have been used with the expected message,
+otherwise the secrecy of the messages and the security for MLS is
+considerably weakened.<a href="#section-8.2.2-2" class="pilcrow">¶</a></p>
 <p id="section-8.2.2-3">PCS means that if a group member's state is compromised at some time t1 but the
 group member subsequently performs an update at some time t2, then all MLS
 guarantees apply to messages sent by the member after time t2, and by other
@@ -3621,7 +3654,7 @@ <h5 id="name-privacy-of-the-group-member">
 <ul class="normal ulEmpty">
 <li class="normal ulEmpty" id="section-8.4.3.2-6.1">
                 <p id="section-8.4.3.2-6.1.1"><strong>RECOMMENDATION:</strong> Ensure that linking between public keys and identities
-only happens in expected scenarios. Otherwise privilege a stronger separation.<a href="#section-8.4.3.2-6.1.1" class="pilcrow">¶</a></p>
+only happens in expected scenarios.<a href="#section-8.4.3.2-6.1.1" class="pilcrow">¶</a></p>
 </li>
             </ul>
 </section>
@@ -3682,6 +3715,7 @@ <h2 id="name-iana-considerations">
 <p id="section-9-1">This document makes no requests of IANA.<a href="#section-9-1" class="pilcrow">¶</a></p>
 </section>
 </div>
+<div id="sec-combined-references">
 <section id="section-10">
       <h2 id="name-references">
 <a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
@@ -3809,6 +3843,7 @@ <h3 id="name-informative-references">
 </section>
 </div>
 </section>
+</div>
 <div id="contributors">
 <section id="appendix-A">
       <h2 id="name-contributors">
@@ -3917,7 +3952,7 @@ <h2 id="name-authors-addresses">
 </address>
 <address class="vcard">
         <div dir="auto" class="left"><span class="fn nameRole">Eric Rescorla</span></div>
-<div dir="auto" class="left"><span class="org">Windy Hill Systems, LLC</span></div>
+<div dir="auto" class="left"><span class="org">Independent</span></div>
 <div class="email">
 <span>Email:</span>
 <a href="mailto:[email protected]" class="email">[email protected]</a>