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

interim-seccons/draft-ietf-core-dns-over-coap.html

@@ -1858,20 +1858,20 @@ <h3 id="name-doc-server">
       <h2 id="name-security-considerations">
 <a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
       </h2>
-<p id="section-8-1">When using unencrypted CoAP (see <a href="#sec_unencrypted-coap" class="auto internal xref">Section 6</a>), setting the ID of a DNS message to 0 as
+<p id="section-8-1">General CoAP security considerations apply.
+Exceeding those 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>,
+the request patterns of DoC make it likely that long-lived security contexts are maintained:
+<span>[<a href="#amp-0rtt" class="cite xref">amp-0rtt</a>]</span> goes into more detail on what needs to be done
+when those are resumed from a new endpoint.<a href="#section-8-1" class="pilcrow">¶</a></p>
+<p id="section-8-2">When using unencrypted CoAP (see <a href="#sec_unencrypted-coap" class="auto internal xref">Section 6</a>), setting the ID of a DNS message to 0 as
 specified in <a href="#sec_req-caching" class="auto internal xref">Section 4.2.2</a> opens the DNS cache of a DoC client to cache poisoning attacks
 via response spoofing.
 This document requires an unpredictable CoAP token in each DoC query from the client when CoAP is
-not secured to mitigate such an attack over DoC (see <a href="#sec_unencrypted-coap" class="auto internal xref">Section 6</a>).<a href="#section-8-1" class="pilcrow">¶</a></p>
-<p id="section-8-2">For encrypted usage with DTLS or OSCORE the impact of a fixed ID on security is limited, as both
+not secured to mitigate such an attack over DoC (see <a href="#sec_unencrypted-coap" class="auto internal xref">Section 6</a>).<a href="#section-8-2" class="pilcrow">¶</a></p>
+<p id="section-8-3">For encrypted usage with DTLS or OSCORE the impact of a fixed ID on security is limited, as both
 harden against injecting spoofed responses.
 Consequently, it is of little concern to leverage the benefits of CoAP caching by setting the ID to
-0.<a href="#section-8-2" class="pilcrow">¶</a></p>
-<p id="section-8-3">General CoAP security considerations apply.
-Exceeding those 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>,
-the request patterns of DoC make it likely that long-lived security contexts are maintained:
-<span>[<a href="#amp-0rtt" class="cite xref">amp-0rtt</a>]</span> goes into more detail on what needs to be done
-when those are resumed from a new address.<a href="#section-8-3" class="pilcrow">¶</a></p>
+0.<a href="#section-8-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="iana-considerations">

interim-seccons/draft-ietf-core-dns-over-coap.txt

@@ -551,6 +551,12 @@ Table of Contents
 
 8.  Security Considerations
 
+   General CoAP security considerations apply.  Exceeding those in
+   Section 11 of [RFC7252], the request patterns of DoC make it likely
+   that long-lived security contexts are maintained: [amp-0rtt] goes
+   into more detail on what needs to be done when those are resumed from
+   a new endpoint.
+
    When using unencrypted CoAP (see Section 6), setting the ID of a DNS
    message to 0 as specified in Section 4.2.2 opens the DNS cache of a
    DoC client to cache poisoning attacks via response spoofing.  This
@@ -563,12 +569,6 @@ Table of Contents
    responses.  Consequently, it is of little concern to leverage the
    benefits of CoAP caching by setting the ID to 0.
 
-   General CoAP security considerations apply.  Exceeding those in
-   Section 11 of [RFC7252], the request patterns of DoC make it likely
-   that long-lived security contexts are maintained: [amp-0rtt] goes
-   into more detail on what needs to be done when those are resumed from
-   a new address.
-
 9.  IANA Considerations
 
 9.1.  New "application/dns-message" Content-Format