Script updating gh-pages from 6795d7d. [ci skip]

carsten-wglc-2/draft-ietf-core-groupcomm-bis.html

@@ -2526,7 +2526,7 @@ <h2 id="name-unsecured-group-communicati">
 <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 <span class="bcp14">MUST NOT</span> 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">A CoAP server in NoSec mode <span class="bcp14">MUST NOT</span> be accessible through the public Internet.
 It is <span class="bcp14">NOT RECOMMENDED</span> 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 specific, well-defined steps that are proven to not require security or to not be able to attain it, 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-4">The possible, exceptional use of the NoSec mode ought to be limited to specific, well-defined "unsecured steps" that unquestionably do not require security or are not able to attain it, 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>). Consistent 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>
@@ -2619,7 +2619,7 @@ <h3 id="name-coap-nosec-mode">
 <p id="section-6.1-1">CoAP group communication, if not protected, is vulnerable to all the attacks mentioned in <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11" class="relref">Section 11</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> for IP multicast. Moreover, as also discussed in <span>[<a href="#I-D.irtf-t2trg-amplification-attacks" class="cite xref">I-D.irtf-t2trg-amplification-attacks</a>]</span>, the NoSec mode is susceptible to source IP address spoofing, hence amplification attacks are especially feasible and greatly effective, since a single request can result in multiple responses from multiple servers (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>).<a href="#section-6.1-1" class="pilcrow">¶</a></p>
 <p id="section-6.1-2">Therefore, it is <span class="bcp14">NOT RECOMMENDED</span> to use CoAP group communication in NoSec mode, also in order to prevent proliferation of high-volume amplification attacks as further discussed in <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>.
 The requirement in <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a> on publically accessible CoAP servers also aims to prevent amplification attacks.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
-<p id="section-6.1-3">Exceptionally, and only after the security implications have been very well considered and understood, some applications may rely on a limited use of the NoSec mode, when performing specific, well-defined steps that are proven to not require security or to not be able to attain it.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
+<p id="section-6.1-3">Exceptionally, and only after the security implications have been very well considered and understood, some applications may rely on a limited use of the NoSec mode, when performing specific, well-defined "unsecured steps" (see <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a>).<a href="#section-6.1-3" class="pilcrow">¶</a></p>
 <p id="section-6.1-4">For example, early link-local discovery of devices and resources as part of an onboarding protocol is a typical use case where the NoSec mode or equivalent unsecured mode is used. In such a discovery step, there may be a querying device that needs to discover nearby devices capable of helping it with the network onboarding process. But there are no mutual security relationships configured on the querying device and its neighbor devices at the time it performs the early discovery. These relationships are configured later in the process based on secure device identities. Alternatively, a new device to be onboarded may wait for advertisements of nearby devices able to help it do the network onboarding process. Also in this case, these messages cannot be secured initially because the new device does not yet have any security relationship configured with devices that are already a member of the network. See <span>[<a href="#I-D.ietf-anima-constrained-voucher" class="cite xref">I-D.ietf-anima-constrained-voucher</a>]</span> for an example of an onboarding protocol that can use CoAP multicast for early link-local discovery.<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 useful in simple applications that neither involve nor may have an impact on sensitive data and personal information. These include, e.g., read-only temperature sensors deployed in an environment where a client reads temperature values but does not use this data to control actuators or to perform other automated actions.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
 <p id="section-6.1-6">In the exception cases where NoSec mode is used, high-volume and harmful amplifications need to be prevented through appropriate and conservative device configurations: taking the early discovery query as an example, only a few CoAP servers are expected to be configured for responding to multicast group requests that are sent for discovery. And the time window during which such unsecured requests are accepted, can be limited as well. Furthermore, the scope is also limited: only link-local requests are accepted.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
@@ -2632,7 +2632,7 @@ <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 specific dynamics of security 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">CoAP group communication <span class="bcp14">MUST</span> 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 specific, well-defined steps that are proven to not require security or to not be able to attain it (e.g., early discovery).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2-2">CoAP group communication <span class="bcp14">MUST</span> 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 specific, well-defined "unsecured steps" (see <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a>).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
 <p id="section-6.2-3">The security considerations from <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-24#section-13" class="relref">Section 13</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">
@@ -2734,7 +2734,7 @@ <h3 id="name-risk-of-amplification">
 <p id="section-6.3-5">Amplification attacks using CoAP are further discussed in <span>[<a href="#I-D.irtf-t2trg-amplification-attacks" class="cite xref">I-D.irtf-t2trg-amplification-attacks</a>]</span>, which also highlights how the amplification factor would become even higher when CoAP group communication is combined with resource observation <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>. That is, a single group request may result in multiple notification responses from each of the responding servers, throughout the observation lifetime.<a href="#section-6.3-5" class="pilcrow">¶</a></p>
 <p id="section-6.3-6">Thus, consistent with <span><a href="https://rfc-editor.org/rfc/rfc7641#section-7" class="relref">Section 7</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>, a server in a CoAP group <span class="bcp14">MUST</span> strictly limit the number of notifications it sends between receiving acknowledgements that confirm the actual interest of the client in continuing the observation.<a href="#section-6.3-6" class="pilcrow">¶</a></p>
 <p id="section-6.3-7">Moreover, it is especially easy to perform an amplification attack when the NoSec mode is used. Therefore, also in order to prevent an easy proliferation of high-volume amplification attacks, it is generally <span class="bcp14">NOT RECOMMENDED</span> to use CoAP group communication in NoSec mode (see <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a>).<a href="#section-6.3-7" class="pilcrow">¶</a></p>
-<p id="section-6.3-8">Besides building on very well understood security implications and being limited to specific, well-defined steps that are proven to not require security or to not be able to attain it, possible exceptions should also be limited to use cases where accesses to a group resource have a specific, narrow, and well understood scope, and where only a few CoAP servers (or, ideally, only one) would possibly respond to a group request.<a href="#section-6.3-8" class="pilcrow">¶</a></p>
+<p id="section-6.3-8">Besides building on very well understood security implications and being limited to specific, well-defined "unsecured steps" (see <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a>), possible exceptions should also be limited to use cases where accesses to a group resource have a specific, narrow, and well understood scope, and where only a few CoAP servers (or, ideally, only one) would possibly respond to a group request.<a href="#section-6.3-8" class="pilcrow">¶</a></p>
 <p id="section-6.3-9">A relevant exceptional example is a CoAP client performing the discovery of hosts such as a Group Manager or a Resource Directory <span>[<a href="#RFC9176" class="cite xref">RFC9176</a>]</span>, by probing for them through a group request sent to the CoAP group. This early, unprotected step is relevant for a CoAP client that does not know the address of such hosts in advance, and that does not yet have configured a mutual security relationship with them. In this kind of deployments, such a discovery procedure does not result in a considerable and harmful amplification, since only the few CoAP servers that are the object of discovery are going to respond to the group request targeting that specific resource. In particular, those hosts can be the only CoAP servers in that specific CoAP group (hence listening for group requests sent to that group), and/or the only CoAP servers explicitly configured to respond to group requests targeting specific group resources.<a href="#section-6.3-9" class="pilcrow">¶</a></p>
 <p id="section-6.3-10">With the exception of such particular use cases, group communications <span class="bcp14">MUST</span> be secured using Group OSCORE <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, see <a href="#chap-oscore" class="auto internal xref">Section 5</a>. As discussed in <a href="#chap-security-considerations-sec-mode-attacks" class="auto internal xref">Section 6.2.3</a>, this limits the feasibility and impact of amplification attacks.<a href="#section-6.3-10" class="pilcrow">¶</a></p>
 </section>

carsten-wglc-2/draft-ietf-core-groupcomm-bis.txt

@@ -2062,9 +2062,9 @@ Table of Contents
    NoSec mode.
 
    The possible, exceptional use of the NoSec mode ought to be limited
-   to specific, well-defined steps that are proven to not require
-   security or to not be able to attain it, e.g., early discovery of
-   devices and resources (see Section 6.1).
+   to specific, well-defined "unsecured steps" that unquestionably do
+   not require security or are not able to attain it, e.g., early
+   discovery of devices and resources (see Section 6.1).
 
    Before possibly and exceptionally using the NoSec mode in such
    circumstances, the security implications in Section 6.1 must be very
@@ -2296,8 +2296,7 @@ Table of Contents
    Exceptionally, and only after the security implications have been
    very well considered and understood, some applications may rely on a
    limited use of the NoSec mode, when performing specific, well-defined
-   steps that are proven to not require security or to not be able to
-   attain it.
+   "unsecured steps" (see Section 4).
 
    For example, early link-local discovery of devices and resources as
    part of an onboarding protocol is a typical use case where the NoSec
@@ -2349,9 +2348,8 @@ Table of Contents
 
    CoAP group communication MUST be protected by using Group OSCORE as
    specified in [I-D.ietf-core-oscore-groupcomm], with the possible
-   exception of specific, well-defined steps that are proven to not
-   require security or to not be able to attain it (e.g., early
-   discovery).
+   exception of specific, well-defined "unsecured steps" (see
+   Section 4).
 
    The security considerations from Section 13 of
    [I-D.ietf-core-oscore-groupcomm] hold for this specification.
@@ -2603,12 +2601,11 @@ Table of Contents
    mode (see Section 6.1).
 
    Besides building on very well understood security implications and
-   being limited to specific, well-defined steps that are proven to not
-   require security or to not be able to attain it, possible exceptions
-   should also be limited to use cases where accesses to a group
-   resource have a specific, narrow, and well understood scope, and
-   where only a few CoAP servers (or, ideally, only one) would possibly
-   respond to a group request.
+   being limited to specific, well-defined "unsecured steps" (see
+   Section 4), possible exceptions should also be limited to use cases
+   where accesses to a group resource have a specific, narrow, and well
+   understood scope, and where only a few CoAP servers (or, ideally,
+   only one) would possibly respond to a group request.
 
    A relevant exceptional example is a CoAP client performing the
    discovery of hosts such as a Group Manager or a Resource Directory