Script updating gh-pages from c98704e. [ci skip]

draft-ietf-schc-8824-update.html

@@ -5780,7 +5780,7 @@ <h2 id="name-security-considerations">
 <p id="section-12-1">The use of SCHC header compression for CoAP header fields only affects the representation of the header information. SCHC header compression itself does not increase or decrease the overall level of security of the communication. When the connection does not use a security protocol (OSCORE, DTLS, etc.), it is necessary to use a Layer 2 security mechanism to protect the SCHC messages.<a href="#section-12-1" class="pilcrow">¶</a></p>
 <p id="section-12-2">If an LPWAN is the Layer 2 technology being used, the SCHC security considerations discussed in <span>[<a href="#RFC8724" class="cite xref">RFC8724</a>]</span> continue to apply. When using another Layer 2 protocol, the use of a cryptographic integrity-protection mechanism to protect the SCHC headers is <span class="bcp14">REQUIRED</span>. Such cryptographic integrity protection is necessary in order to continue to provide the properties that <span>[<a href="#RFC8724" class="cite xref">RFC8724</a>]</span> relies upon.<a href="#section-12-2" class="pilcrow">¶</a></p>
 <p id="section-12-3">When SCHC is used with OSCORE, the security considerations discussed in <span>[<a href="#RFC8613" class="cite xref">RFC8613</a>]</span> continue to apply. When SCHC is used with Group OSCORE, the security considerations discussed in <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> apply. When SCHC is used in the presence of CoAP proxies, the security considerations discussed in <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11.2" class="relref">Section 11.2</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> continue to apply.<a href="#section-12-3" class="pilcrow">¶</a></p>
-<p id="section-12-4">When SCHC is used with the OSCORE Outer headers, the Initialization Vector (IV) size in the Compression Residue must be carefully selected. There is a trade-off between compression efficiency (with a longer MSB MO prefix) and the frequency at which the Device must renew its key material (in order to prevent the IV from expanding to an uncompressible value). The key-renewal operation itself may require several message exchanges and result in energy-intensive computation, but the optimal trade-off will depend on the specifics of the Device and expected usage patterns. In order to renew its key material with another OSCORE endpoint, the Device can rely on the lightweight key update protocol KUDOS defined in <span>[<a href="#I-D.ietf-core-oscore-key-update" class="cite xref">I-D.ietf-core-oscore-key-update</a>]</span>.<a href="#section-12-4" class="pilcrow">¶</a></p>
+<p id="section-12-4">When SCHC is used with the OSCORE Outer headers, the Initialization Vector (IV) size in the Compression Residue must be carefully selected. There is a trade-off between compression efficiency (with a longer MSB MO prefix) and the frequency at which the Device must renew its key material (in order to prevent the IV from expanding to an incompressible value). The key-renewal operation itself may require several message exchanges and result in energy-intensive computation, but the optimal trade-off will depend on the specifics of the Device and expected usage patterns. In order to renew its key material with another OSCORE endpoint, the Device can rely on the lightweight key update protocol KUDOS defined in <span>[<a href="#I-D.ietf-core-oscore-key-update" class="cite xref">I-D.ietf-core-oscore-key-update</a>]</span>.<a href="#section-12-4" class="pilcrow">¶</a></p>
 <p id="section-12-5">If an attacker can introduce a corrupted SCHC-compressed packet onto a link, DoS attacks can be mounted by causing excessive resource consumption at the decompressor. However, an attacker able to inject packets at the link layer is also capable of other, potentially more damaging, attacks.<a href="#section-12-5" class="pilcrow">¶</a></p>
 <p id="section-12-6">SCHC compression emits variable-length Compression Residues for some CoAP fields. In the representation of the compressed header, the length field that is sent is not the length of the original header field but rather the length of the Compression Residue that is being transmitted. If a corrupted packet arrives at the decompressor with a longer or shorter length than that of the original compressed representation, the SCHC decompression procedures will detect an error and drop the packet.<a href="#section-12-6" class="pilcrow">¶</a></p>
 <p id="section-12-7">SCHC header compression Rules <span class="bcp14">MUST</span> remain tightly coupled between the compressor and the decompressor. If the compression Rules get out of sync, a Compression Residue might be decompressed differently at the receiver, thus yielding a result different than the initial message submitted to compression procedures. Accordingly, any time the context Rules are updated on an OSCORE endpoint, that endpoint <span class="bcp14">MUST</span> trigger OSCORE key re-establishment, e.g., by running the lightweight key update protocol KUDOS <span>[<a href="#I-D.ietf-core-oscore-key-update" class="cite xref">I-D.ietf-core-oscore-key-update</a>]</span>. Similar procedures may be appropriate to signal Rule updates when other message-protection mechanisms are in use.<a href="#section-12-7" class="pilcrow">¶</a></p>

draft-ietf-schc-8824-update.txt

@@ -3068,7 +3068,7 @@ Table of Contents
    selected.  There is a trade-off between compression efficiency (with
    a longer MSB MO prefix) and the frequency at which the Device must
    renew its key material (in order to prevent the IV from expanding to
-   an uncompressible value).  The key-renewal operation itself may
+   an incompressible value).  The key-renewal operation itself may
    require several message exchanges and result in energy-intensive
    computation, but the optimal trade-off will depend on the specifics
    of the Device and expected usage patterns.  In order to renew its key