Script updating gh-pages from 98d1740. [ci skip]

draft-ietf-core-oscore-key-limits.html

@@ -1335,7 +1335,7 @@ <h4 id="name-limits-for-q-and-v">
 <a href="#name-maximum-length-of-each-mess" class="selfRef">Maximum length of each message (in bytes)</a>
             </figcaption></figure>
 </div>
-<p id="section-2.1.1-7">With regards to the limit for 'l', the recommended 'l' value for the algorithms shown in <a href="#algorithm-limits" class="auto internal xref">Figure 1</a>, and for AEAD_AES_128_CCM_8, is 2^10 (16384 bytes) and 2^8 (4096 bytes) respectively. Considering that a typical MTU size is 1500 bytes, and the fact that the maximum block size when using block-wise transfers with CoAP is 1024 bytes (see <span><a href="https://rfc-editor.org/rfc/rfc7959#section-2" class="relref">Section 2</a> of [<a href="#RFC7959" class="cite xref">RFC7959</a>]</span>), it is unlikely that a larger size of 'l' than what is recommended makes sense to use in typical network setups.<a href="#section-2.1.1-7" class="pilcrow">¶</a></p>
+<p id="section-2.1.1-7">With regards to the limit for 'l', the recommended 'l' value for the algorithms shown in <a href="#algorithm-limits" class="auto internal xref">Figure 1</a>, and for AEAD_AES_128_CCM_8, is 2^10 (16384 bytes) and 2^8 (4096 bytes) respectively. Considering a typical MTU size of 1500 bytes, and the fact that the maximum block size when using block-wise transfers with CoAP is 1024 bytes (see <span><a href="https://rfc-editor.org/rfc/rfc7959#section-2" class="relref">Section 2</a> of [<a href="#RFC7959" class="cite xref">RFC7959</a>]</span>), it is unlikely that a larger size of 'l' than what is recommended makes sense to use in typical network setups.<a href="#section-2.1.1-7" class="pilcrow">¶</a></p>
 <p id="section-2.1.1-8">However, although under typical circumstances an 'l' limit of 2^8 (4096 bytes) is acceptable, exceptional cases can warrant a higher value of 'l'. For instance, Block-wise Extension for Reliable Transport (BERT) extends the CoAP Block-Wise tranfer functionality, enabling use of larger messages over reliable transports such as TCP or WebSockets (see <span>[<a href="#RFC8323" class="cite xref">RFC8323</a>]</span>). In case the OSCORE peers wish to take advantage of BERT functionality it becomes essential to opt for a higher value of 'l'. Thus accommodating the larger data chunks that can be used for BERT Block-Wise transfers.<a href="#section-2.1.1-8" class="pilcrow">¶</a></p>
 <p id="section-2.1.1-9">An alternative means of allowing for larger values of 'l', while still maintaining the security properties of the used AEAD algorithm, is to adjust the 'q' and 'v' values to compensate. In practice, this means reducing the size of 'q' and 'v', considering the new value of 'l', to ensure an acceptably low value of the IA and CA probabilities. A reasonable target for the IA and CA probabilities values is the threshold value of 2^-50 defined in <span>[<a href="#I-D.irtf-cfrg-aead-limits" class="cite xref">I-D.irtf-cfrg-aead-limits</a>]</span>.<a href="#section-2.1.1-9" class="pilcrow">¶</a></p>
 </section>

draft-ietf-core-oscore-key-limits.txt

@@ -242,8 +242,8 @@ Table of Contents
 
    With regards to the limit for 'l', the recommended 'l' value for the
    algorithms shown in Figure 1, and for AEAD_AES_128_CCM_8, is 2^10
-   (16384 bytes) and 2^8 (4096 bytes) respectively.  Considering that a
-   typical MTU size is 1500 bytes, and the fact that the maximum block
+   (16384 bytes) and 2^8 (4096 bytes) respectively.  Considering a
+   typical MTU size of 1500 bytes, and the fact that the maximum block
    size when using block-wise transfers with CoAP is 1024 bytes (see
    Section 2 of [RFC7959]), it is unlikely that a larger size of 'l'
    than what is recommended makes sense to use in typical network