Script updating gh-pages from 9ed9eba. [ci skip]

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

@@ -2527,8 +2527,8 @@ <h2 id="name-unsecured-group-communicati">
 <p id="section-4-1">CoAP group communication can operate in CoAP NoSec (No Security) mode, without using application-layer and transport-layer security mechanisms. The NoSec mode uses the "coap" scheme, and is defined in <span><a href="https://rfc-editor.org/rfc/rfc7252#section-9" class="relref">Section 9</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>.<a href="#section-4-1" class="pilcrow">¶</a></p>
 <p id="section-4-2">The NoSec mode does not require and does not make use of a security group. Indications that endpoints can use the NoSec mode MUST NOT rely on setting up and advertising a pseudo security group with name "NoSec" or any of its lowercase/uppercase combinations.<a href="#section-4-2" class="pilcrow">¶</a></p>
 <p id="section-4-3">It is NOT RECOMMENDED to use CoAP group communication in NoSec mode.<a href="#section-4-3" class="pilcrow">¶</a></p>
-<p id="section-4-4">The possible, exceptional use of the NoSec mode ought to be limited to non-sensitive and non-critical applications for which it is relevant, such as early discovery of devices and resources (see <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a>).<a href="#section-4-4" class="pilcrow">¶</a></p>
-<p id="section-4-5">Before possibly and exceptionally using the NoSec mode in such applications, the security implications in <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a> must be very well considered and understood, especially as to the risk and impact of amplification attacks (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>). Consistently with such security implications, the use of the NoSec mode should still be avoided whenever possible.<a href="#section-4-5" class="pilcrow">¶</a></p>
+<p id="section-4-4">The possible, exceptional use of the NoSec mode ought to be limited to: applications that are proven to be neither sensitive nor critical; and specific, well-defined steps where security is not viable or is intrinsically unattainable, e.g., early discovery of devices and resources (see <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a>).<a href="#section-4-4" class="pilcrow">¶</a></p>
+<p id="section-4-5">Before possibly and exceptionally using the NoSec mode in such circumstances, the security implications in <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a> must be very well considered and understood, especially as to the risk and impact of amplification attacks (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>). Consistently with such security implications, the use of the NoSec mode should still be avoided whenever possible.<a href="#section-4-5" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="chap-oscore">
@@ -2621,7 +2621,7 @@ <h3 id="name-coap-nosec-mode">
 <p id="section-6.1-3">Exceptionally, and only after the security implications have been very well considered and understood, some non-sensitive and non-critical applications may rely on a limited and well-defined use of the NoSec mode.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
 <p id="section-6.1-4">For example, early discovery of devices and resources is a typical use case where the NoSec mode is relevant to use. In such a situation, the querying devices do not have yet configured any mutual security relations at the time they perform the discovery. Also, high-volume and harmful amplifications can be prevented through appropriate and conservative configurations, since only a few CoAP servers are expected to be configured for responding to the group requests sent for discovery (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>).<a href="#section-6.1-4" class="pilcrow">¶</a></p>
 <p id="section-6.1-5">As a further example, the NoSec mode may be relevant to use in non-critical applications that neither involve nor may have an impact on sensitive data and personal sphere. These include, e.g., read-only temperature sensors deployed in non-sensitive environments, where the client reads out the values but does not use the data to control actuators or to base important decisions on.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
-<p id="section-6.1-6">Except for the class of applications discussed above, and all the more so in sensitive and mission-critical applications (e.g., health monitoring systems and alarm monitoring systems), CoAP group communication MUST NOT be used in NoSec mode.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
+<p id="section-6.1-6">Except for the class of applications discussed above, and all the more so in sensitive and/or critical applications (e.g., health monitoring systems and alarm monitoring systems), CoAP group communication MUST NOT be used in NoSec mode.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="chap-security-considerations-sec-mode">
@@ -2630,7 +2630,8 @@ <h3 id="name-group-oscore-2">
 <a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-group-oscore-2" class="section-name selfRef">Group OSCORE</a>
         </h3>
 <p id="section-6.2-1">Group OSCORE provides end-to-end application-level security. This has many desirable properties, including maintaining security assurances while forwarding traffic through intermediaries (proxies). Application-level security also tends to more cleanly separate security from the dynamics of group membership (e.g., the problem of distributing security keys across large groups with many members that come and go).<a href="#section-6.2-1" class="pilcrow">¶</a></p>
-<p id="section-6.2-2">For sensitive and mission-critical applications, CoAP group communication MUST be protected by using Group OSCORE as specified in <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>. The same security considerations from <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-11" class="relref">Section 11</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> hold for this specification.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2-2">CoAP group communication MUST be protected by using Group OSCORE as specified in <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, with the possible exception of: applications that are proven to be neither sensitive nor critical; and specific, well-defined steps where security is not viable or is intrinsically unattainable (e.g., early discovery).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2-3">The same security considerations from <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-11" class="relref">Section 11</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> hold for this specification.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
 <div id="chap-security-considerations-sec-mode-key-mgmt">
 <section id="section-6.2.1">
           <h4 id="name-group-key-management">
@@ -3845,7 +3846,10 @@ <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">Editorial fixes and improvements.<a href="#appendix-E.1-1.4.1" class="pilcrow">¶</a></p>
+            <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>
+</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>
 </li>
         </ul>
 </section>

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

@@ -2040,12 +2040,13 @@ Table of Contents
    It is NOT RECOMMENDED to use CoAP group communication in NoSec mode.
 
    The possible, exceptional use of the NoSec mode ought to be limited
-   to non-sensitive and non-critical applications for which it is
-   relevant, such as early discovery of devices and resources (see
-   Section 6.1).
+   to: applications that are proven to be neither sensitive nor
+   critical; and specific, well-defined steps where security is not
+   viable or is intrinsically unattainable, e.g., early discovery of
+   devices and resources (see Section 6.1).
 
    Before possibly and exceptionally using the NoSec mode in such
-   applications, the security implications in Section 6.1 must be very
+   circumstances, the security implications in Section 6.1 must be very
    well considered and understood, especially as to the risk and impact
    of amplification attacks (see Section 6.3).  Consistently with such
    security implications, the use of the NoSec mode should still be
@@ -2282,7 +2283,7 @@ Table of Contents
    actuators or to base important decisions on.
 
    Except for the class of applications discussed above, and all the
-   more so in sensitive and mission-critical applications (e.g., health
+   more so in sensitive and/or critical applications (e.g., health
    monitoring systems and alarm monitoring systems), CoAP group
    communication MUST NOT be used in NoSec mode.
 
@@ -2296,11 +2297,14 @@ Table of Contents
    distributing security keys across large groups with many members that
    come and go).
 
-   For sensitive and mission-critical applications, CoAP group
-   communication MUST be protected by using Group OSCORE as specified in
-   [I-D.ietf-core-oscore-groupcomm].  The same security considerations
-   from Section 11 of [I-D.ietf-core-oscore-groupcomm] hold for this
-   specification.
+   CoAP group communication MUST be protected by using Group OSCORE as
+   specified in [I-D.ietf-core-oscore-groupcomm], with the possible
+   exception of: applications that are proven to be neither sensitive
+   nor critical; and specific, well-defined steps where security is not
+   viable or is intrinsically unattainable (e.g., early discovery).
+
+   The same security considerations from Section 11 of
+   [I-D.ietf-core-oscore-groupcomm] hold for this specification.
 
 6.2.1.  Group Key Management
 
@@ -3797,6 +3801,8 @@ E.1.  Version -09 to -10
    *  Changed "has to" to "should" for enforcing access control based on
       membership to security groups.
 
+   *  Further stressed that group communication ought to be secured.
+
    *  Editorial fixes and improvements.
 
 E.2.  Version -08 to -09