Script updating gh-pages from 2d1f2c9. [ci skip]

john-comments/draft-ietf-core-groupcomm-bis.html

@@ -2638,11 +2638,22 @@ <h4 id="name-group-key-management">
 <a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-group-key-management" class="section-name selfRef">Group Key Management</a>
           </h4>
 <p id="section-6.2.1-1">A key management scheme for secure revocation and renewal of group security material, namely group rekeying, is required to be adopted in OSCORE groups. The key management scheme has to preserve forward security in the OSCORE group, as well as backward security if this is required by the application (see <a href="#chap-sec-group-maintenance" class="auto internal xref">Section 5.2</a>). In particular, the key management scheme MUST comply with the functional steps defined in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-3.2" class="relref">Section 3.2</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>.<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-2">Group policies should also take into account the time that the key management scheme requires to rekey the group, on one hand, and the expected frequency of group membership changes, i.e., nodes joining and leaving, on the other hand.<a href="#section-6.2.1-2" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-3">That is, it may be desirable to not rekey the group upon every single membership change, in case members frequently joining and leaving, and at the same time a single group rekeying instance taking a non-negligible time to complete.<a href="#section-6.2.1-3" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-4">In such a case, the Group Manager may cautiously consider to rekey the group, e.g., after a minimum number of nodes has joined or left the group within a pre-defined time interval, or according to communication patterns with predictable time intervals of network inactivity. This would prevent from paralyzing communications in the group, when a slow rekeying scheme is used and frequently invoked.<a href="#section-6.2.1-4" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-5">At the same time, the security implications of delaying the rekeying process have to be carefully considered and understood before employing such group policies.<a href="#section-6.2.1-5" class="pilcrow">¶</a></p>
-<p id="section-6.2.1-6">In fact, this comes at the cost of not continuously preserving backward and forward security, since group rekeying might not occur upon every single group membership change. That is, most recently joined nodes would have access to the security material used prior to their joining, and thus be able to access past group communications protected with that security material. Similarly, until the group is rekeyed, most recently left nodes would retain access to group communications protected with the existing security material.<a href="#section-6.2.1-6" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-2">Even though group policies vary depending on the specific applications and their security requirements, they SHOULD also take into account:<a href="#section-6.2.1-2" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-6.2.1-3.1">
+              <p id="section-6.2.1-3.1.1">The expected amount of time that the key management scheme requires to rekey the group.<a href="#section-6.2.1-3.1.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-6.2.1-3.2">
+              <p id="section-6.2.1-3.2.1">The expected frequency of group membership changes (i.e., nodes joining and leaving).<a href="#section-6.2.1-3.2.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-6.2.1-3.3">
+              <p id="section-6.2.1-3.3.1">The identity of the specific CoAP endpoints as they join and leave the OSCORE group.<a href="#section-6.2.1-3.3.1" class="pilcrow">¶</a></p>
+</li>
+          </ul>
+<p id="section-6.2.1-4">In particular, it can be desirable to not rekey the group upon every single membership change, in case group members frequently join and leave, and at the same time a single group rekeying instance takes a non-negligible time to complete.<a href="#section-6.2.1-4" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-5">In such a case, the Group Manager can cautiously consider to rekey the group, e.g., after a minimum number of nodes has joined or left the group within a pre-defined time interval, or according to communication patterns with predictable time intervals of network inactivity. This would prevent from paralyzing communications in the group, when a slow rekeying scheme is used and frequently invoked.<a href="#section-6.2.1-5" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-6">At the same time, the security implications of delaying the rekeying process have to be carefully considered and understood before employing such group policies.<a href="#section-6.2.1-6" class="pilcrow">¶</a></p>
+<p id="section-6.2.1-7">In fact, this comes at the cost of not continuously preserving backward and forward security, since group rekeying might not occur upon every single group membership change. That is, most recently joined nodes would have access to the security material used prior to their joining, and thus be able to access past group communications protected with that security material. Similarly, until the group is rekeyed, most recently left nodes would retain access to group communications protected with the existing security material.<a href="#section-6.2.1-7" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="chap-security-considerations-sec-mode-sauth">
@@ -3846,10 +3857,13 @@ <h3 id="name-version-09-to-10">
             <p id="appendix-E.1-1.3.1">Changed "has to" to "should" for enforcing access control based on membership to security groups.<a href="#appendix-E.1-1.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.4">
-            <p id="appendix-E.1-1.4.1">Further stressed that group communication ought to be secured.<a href="#appendix-E.1-1.4.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.4.1">Used normative language for policies about group rekeying.<a href="#appendix-E.1-1.4.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.5">
-            <p id="appendix-E.1-1.5.1">Editorial fixes and improvements.<a href="#appendix-E.1-1.5.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.5.1">Further stressed that group communication ought to be secured.<a href="#appendix-E.1-1.5.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-E.1-1.6">
+            <p id="appendix-E.1-1.6.1">Editorial fixes and improvements.<a href="#appendix-E.1-1.6.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>

john-comments/draft-ietf-core-groupcomm-bis.txt

@@ -2316,17 +2316,25 @@ Table of Contents
    key management scheme MUST comply with the functional steps defined
    in Section 3.2 of [I-D.ietf-core-oscore-groupcomm].
 
-   Group policies should also take into account the time that the key
-   management scheme requires to rekey the group, on one hand, and the
-   expected frequency of group membership changes, i.e., nodes joining
-   and leaving, on the other hand.
+   Even though group policies vary depending on the specific
+   applications and their security requirements, they SHOULD also take
+   into account:
 
-   That is, it may be desirable to not rekey the group upon every single
-   membership change, in case members frequently joining and leaving,
-   and at the same time a single group rekeying instance taking a non-
-   negligible time to complete.
+   *  The expected amount of time that the key management scheme
+      requires to rekey the group.
 
-   In such a case, the Group Manager may cautiously consider to rekey
+   *  The expected frequency of group membership changes (i.e., nodes
+      joining and leaving).
+
+   *  The identity of the specific CoAP endpoints as they join and leave
+      the OSCORE group.
+
+   In particular, it can be desirable to not rekey the group upon every
+   single membership change, in case group members frequently join and
+   leave, and at the same time a single group rekeying instance takes a
+   non-negligible time to complete.
+
+   In such a case, the Group Manager can cautiously consider to rekey
    the group, e.g., after a minimum number of nodes has joined or left
    the group within a pre-defined time interval, or according to
    communication patterns with predictable time intervals of network
@@ -3801,6 +3809,8 @@ E.1.  Version -09 to -10
    *  Changed "has to" to "should" for enforcing access control based on
       membership to security groups.
 
+   *  Used normative language for policies about group rekeying.
+
    *  Further stressed that group communication ought to be secured.
 
    *  Editorial fixes and improvements.