Script updating gh-pages from 7a21ada. [ci skip]

draft-ietf-core-groupcomm-proxy.html

@@ -2740,7 +2740,7 @@ <h3 id="name-group-etag-option">
 <p id="section-10.4-1">The Group-ETag Option is of class U for OSCORE <span>[<a href="#RFC8613" class="cite xref">RFC8613</a>]</span>. Hence, also when Group OSCORE is used between the client and the servers <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, a proxy is able to access the option value and use it to possibly perform response revalidation at its cache entries associated with the servers in the CoAP group, as well as to remove the option altogether before forwarding the group request to the servers. When a chain of proxies is used (see <a href="#sec-proxy-chain" class="auto internal xref">Section 8</a>), this also allows each proxy but the last one in the chain to update the option value, to possibly ask the next hop towards the origin servers to perform response revalidation at its cache entries.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
 <p id="section-10.4-2">The security association between the client and the proxy <span class="bcp14">MUST</span> provide message integrity, so that further intermediaries between the two as well as on-path active adversaries are not able to undetectably remove the option or alter its content, before the group request reaches the proxy.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
 <p id="section-10.4-3">Removing the option would result in the proxy not performing response revalidation at its cache entries associated with the servers in the CoAP group, even though that was what the client asked for.<a href="#section-10.4-3" class="pilcrow">¶</a></p>
-<p id="section-10.4-4">Altering the option content in a group request would result in the proxy failing the response revalidation and hence not replying with a single 2.03 (Valid) response, but instead with multiple 2.05 (Content) responses conveying the full resource representations from its cache entries. Instead, altering the option content in a 2.03 (Valid) or 2.05 (Content) response would result in the client wrongly believing that the already stored or the just received representation, respectively, is also the current one, as per the entity value of the tampered Group-ETag Option.<a href="#section-10.4-4" class="pilcrow">¶</a></p>
+<p id="section-10.4-4">Altering the option content in a group request would result in the proxy performing response revalidation based on different entity-tag values from those actually specified by the client. Consequently, the proxy would erroneously reply with multiple 2.05 (Content) responses conveying the full resource representations from its cache entries instead of with a single 2.03 (Valid) response, or vice versa. Instead, altering the option content in a 2.03 (Valid) or 2.05 (Content) response would result in the client wrongly believing that the already stored or the just received representation, respectively, is also the current one, as per the entity value of the tampered Group-ETag Option.<a href="#section-10.4-4" class="pilcrow">¶</a></p>
 <p id="section-10.4-5">The security association between the client and the proxy <span class="bcp14">SHOULD</span> also provide message confidentiality. Otherwise, any further intermediaries between the two as well as any on-path passive adversaries would be able to access the option content, and thus learn the rate and pattern according to which the group resource in question changes over time, as inferable from the entity values read over time.<a href="#section-10.4-5" class="pilcrow">¶</a></p>
 <p id="section-10.4-6">When the client protects the unicast request sent to the proxy using OSCORE (see <span>[<a href="#I-D.ietf-core-oscore-capable-proxies" class="cite xref">I-D.ietf-core-oscore-capable-proxies</a>]</span>) and/or (D)TLS, both message integrity and message confidentiality are achieved in the leg between the client and the proxy.<a href="#section-10.4-6" class="pilcrow">¶</a></p>
 <p id="section-10.4-7">The same considerations above about security associations apply when a chain of proxies is used (see <a href="#sec-proxy-chain" class="auto internal xref">Section 8</a>), with each proxy but the last one in the chain acting as client with the next hop towards the origin servers.<a href="#section-10.4-7" class="pilcrow">¶</a></p>

draft-ietf-core-groupcomm-proxy.txt

@@ -2102,14 +2102,16 @@ Table of Contents
    CoAP group, even though that was what the client asked for.
 
    Altering the option content in a group request would result in the
-   proxy failing the response revalidation and hence not replying with a
-   single 2.03 (Valid) response, but instead with multiple 2.05
-   (Content) responses conveying the full resource representations from
-   its cache entries.  Instead, altering the option content in a 2.03
-   (Valid) or 2.05 (Content) response would result in the client wrongly
-   believing that the already stored or the just received
-   representation, respectively, is also the current one, as per the
-   entity value of the tampered Group-ETag Option.
+   proxy performing response revalidation based on different entity-tag
+   values from those actually specified by the client.  Consequently,
+   the proxy would erroneously reply with multiple 2.05 (Content)
+   responses conveying the full resource representations from its cache
+   entries instead of with a single 2.03 (Valid) response, or vice
+   versa.  Instead, altering the option content in a 2.03 (Valid) or
+   2.05 (Content) response would result in the client wrongly believing
+   that the already stored or the just received representation,
+   respectively, is also the current one, as per the entity value of the
+   tampered Group-ETag Option.
 
    The security association between the client and the proxy SHOULD also
    provide message confidentiality.  Otherwise, any further