Script updating gh-pages from 26513ea. [ci skip]

Author: ID Bot

draft-denis-dprive-dnscrypt.html

@@ -1508,7 +1508,7 @@ <h2 id="name-protocol-components">
           <p id="section-4-3.6.1"><code>&lt;client-nonce&gt;</code>: a unique query identifier for a given (<code>&lt;client-sk&gt;</code>, <code>&lt;resolver-pk&gt;</code>) tuple. Every newly encrypted DNSCrypt query for the same (<code>&lt;client-sk&gt;</code>, <code>&lt;resolver-pk&gt;</code>) tuple <span class="bcp14">MUST</span> use a distinct <code>&lt;client-nonce&gt;</code> value, even when the plaintext DNS query is being retried. Retransmitting the same already-encrypted DNSCrypt packet does not require changing its nonce. The length of <code>&lt;client-nonce&gt;</code> is determined by the chosen encryption algorithm.<a href="#section-4-3.6.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-4-3.7">
-          <p id="section-4-3.7.1"><code>AE</code>: the authenticated encryption function.<a href="#section-4-3.7.1" class="pilcrow">¶</a></p>
+          <p id="section-4-3.7.1"><code>AE</code>: the authenticated encryption function. For the encryption systems defined in this document, it is the <code>XChaCha20_DJB-Poly1305</code> construction of Appendix 1, whose output is the 16-byte authentication tag followed by the ciphertext.<a href="#section-4-3.7.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-4-3.8">
           <p id="section-4-3.8.1"><code>&lt;encrypted-query&gt;</code>: <code>AE(&lt;shared-key&gt; &lt;client-nonce&gt; &lt;client-nonce-pad&gt;, &lt;client-query&gt; &lt;client-query-pad&gt;)</code><a href="#section-4-3.8.1" class="pilcrow">¶</a></p>
@@ -1550,7 +1550,7 @@ <h2 id="name-protocol-components">
           <p id="section-4-5.7.1"><code>&lt;resolver-nonce&gt;</code>: a unique response identifier for a given <code>(&lt;client-pk&gt;, &lt;resolver-sk&gt;)</code> tuple. The length of <code>&lt;resolver-nonce&gt;</code> depends on the chosen encryption algorithm.<a href="#section-4-5.7.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-4-5.8">
-          <p id="section-4-5.8.1"><code>AE</code>: the authenticated encryption function.<a href="#section-4-5.8.1" class="pilcrow">¶</a></p>
+          <p id="section-4-5.8.1"><code>AE</code>: the authenticated encryption function. For the encryption systems defined in this document, it is the <code>XChaCha20_DJB-Poly1305</code> construction of Appendix 1, whose output is the 16-byte authentication tag followed by the ciphertext.<a href="#section-4-5.8.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-4-5.9">
           <p id="section-4-5.9.1"><code>&lt;encrypted-response&gt;</code>: <code>AE(&lt;shared-key&gt;, &lt;nonce&gt;, &lt;resolver-response&gt; &lt;resolver-response-pad&gt;)</code><a href="#section-4-5.9.1" class="pilcrow">¶</a></p>
@@ -1830,7 +1830,7 @@ <h3 id="name-certificates">
             <p id="section-5.5-18.2.1"><code>&lt;cert-magic&gt;</code>: <code>0x44 0x4e 0x53 0x43</code><a href="#section-5.5-18.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-5.5-18.3">
-            <p id="section-5.5-18.3.1"><code>&lt;es-version&gt;</code>: the cryptographic construction to use with this certificate. For Box-XChaChaPoly, <code>&lt;es-version&gt;</code> <span class="bcp14">MUST</span> be <code>0x00 0x02</code>.<a href="#section-5.5-18.3.1" class="pilcrow">¶</a></p>
+            <p id="section-5.5-18.3.1"><code>&lt;es-version&gt;</code>: the cryptographic construction to use with this certificate. For the <code>Box-XChaChaPoly</code> construction of Appendix 1, that is, the X25519 key exchange with the <code>XChaCha20_DJB-Poly1305</code> authenticated encryption algorithm, <code>&lt;es-version&gt;</code> <span class="bcp14">MUST</span> be <code>0x00 0x02</code>.<a href="#section-5.5-18.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-5.5-18.4">
             <p id="section-5.5-18.4.1"><code>&lt;protocol-minor-version&gt;</code>: <code>0x00 0x00</code><a href="#section-5.5-18.4.1" class="pilcrow">¶</a></p>
@@ -1858,21 +1858,22 @@ <h3 id="name-certificates">
 </li>
         </ul>
 <p id="section-5.5-19">Certificates made of this information, without extensions, are 116 bytes long. With the addition of <code>&lt;cert-magic&gt;</code>, <code>&lt;es-version&gt;</code>, and <code>&lt;protocol-minor-version&gt;</code>, the record is 124 bytes long.<a href="#section-5.5-19" class="pilcrow">¶</a></p>
-<p id="section-5.5-20">After receiving a set of certificates, the client checks their validity based on the current date, filters out the ones designed for encryption systems that are not supported by the client, and chooses the certificate with the higher serial number.<a href="#section-5.5-20" class="pilcrow">¶</a></p>
-<p id="section-5.5-21">DNSCrypt queries sent by the client <span class="bcp14">MUST</span> use the <code>&lt;client-magic&gt;</code> header of the chosen certificate, as well as the specified encryption system and public key.<a href="#section-5.5-21" class="pilcrow">¶</a></p>
-<p id="section-5.5-22">The client <span class="bcp14">MUST</span> check for new certificates every hour and switch to a new certificate if:<a href="#section-5.5-22" class="pilcrow">¶</a></p>
+<p id="section-5.5-20">Within a <code>TXT</code> record, the certificate is carried in the record's RDATA, which is a sequence of length-prefixed character-strings <span>[<a href="#RFC1035" class="cite xref">RFC1035</a>]</span>. A client reconstructs the certificate by concatenating these character-strings in order, after removing the single length octet that precedes each one. A 124-byte classical certificate fits in a single character-string, whereas a larger certificate spans several character-strings that <span class="bcp14">MUST</span> be concatenated in this way before the certificate is parsed.<a href="#section-5.5-20" class="pilcrow">¶</a></p>
+<p id="section-5.5-21">After receiving a set of certificates, the client checks their validity based on the current date, filters out the ones designed for encryption systems that are not supported by the client, and chooses the certificate with the higher serial number.<a href="#section-5.5-21" class="pilcrow">¶</a></p>
+<p id="section-5.5-22">DNSCrypt queries sent by the client <span class="bcp14">MUST</span> use the <code>&lt;client-magic&gt;</code> header of the chosen certificate, as well as the specified encryption system and public key.<a href="#section-5.5-22" class="pilcrow">¶</a></p>
+<p id="section-5.5-23">The client <span class="bcp14">MUST</span> check for new certificates every hour and switch to a new certificate if:<a href="#section-5.5-23" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-5.5-23.1">
-            <p id="section-5.5-23.1.1">The current certificate is not present or not valid anymore,<a href="#section-5.5-23.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-5.5-24.1">
+            <p id="section-5.5-24.1.1">The current certificate is not present or not valid anymore,<a href="#section-5.5-24.1.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-5.5-24">or<a href="#section-5.5-24" class="pilcrow">¶</a></p>
+<p id="section-5.5-25">or<a href="#section-5.5-25" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-5.5-25.1">
-            <p id="section-5.5-25.1.1">A certificate with a higher serial number than the current one is available.<a href="#section-5.5-25.1.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-5.5-26.1">
+            <p id="section-5.5-26.1.1">A certificate with a higher serial number than the current one is available.<a href="#section-5.5-26.1.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-5.5-26">The certificate management system ensures that cryptographic keys remain fresh and that clients can smoothly transition to updated certificates. With the core protocol mechanics now established, we can examine implementation considerations.<a href="#section-5.5-26" class="pilcrow">¶</a></p>
+<p id="section-5.5-27">The certificate management system ensures that cryptographic keys remain fresh and that clients can smoothly transition to updated certificates. With the core protocol mechanics now established, we can examine implementation considerations.<a href="#section-5.5-27" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

draft-denis-dprive-dnscrypt.txt

@@ -276,7 +276,10 @@ Table of Contents
       of <client-nonce> is determined by the chosen encryption
       algorithm.
 
-   *  AE: the authenticated encryption function.
+   *  AE: the authenticated encryption function.  For the encryption
+      systems defined in this document, it is the XChaCha20_DJB-Poly1305
+      construction of Appendix 1, whose output is the 16-byte
+      authentication tag followed by the ciphertext.
 
    *  <encrypted-query>: AE(<shared-key> <client-nonce> <client-nonce-
       pad>, <client-query> <client-query-pad>)
@@ -313,7 +316,10 @@ Table of Contents
       (<client-pk>, <resolver-sk>) tuple.  The length of <resolver-
       nonce> depends on the chosen encryption algorithm.
 
-   *  AE: the authenticated encryption function.
+   *  AE: the authenticated encryption function.  For the encryption
+      systems defined in this document, it is the XChaCha20_DJB-Poly1305
+      construction of Appendix 1, whose output is the 16-byte
+      authentication tag followed by the ciphertext.
 
    *  <encrypted-response>: AE(<shared-key>, <nonce>, <resolver-
       response> <resolver-response-pad>)
@@ -689,7 +695,10 @@ Table of Contents
    *  <cert-magic>: 0x44 0x4e 0x53 0x43
 
    *  <es-version>: the cryptographic construction to use with this
-      certificate.  For Box-XChaChaPoly, <es-version> MUST be 0x00 0x02.
+      certificate.  For the Box-XChaChaPoly construction of Appendix 1,
+      that is, the X25519 key exchange with the XChaCha20_DJB-Poly1305
+      authenticated encryption algorithm, <es-version> MUST be 0x00
+      0x02.
 
    *  <protocol-minor-version>: 0x00 0x00
 
@@ -728,6 +737,15 @@ Table of Contents
    bytes long.  With the addition of <cert-magic>, <es-version>, and
    <protocol-minor-version>, the record is 124 bytes long.
 
+   Within a TXT record, the certificate is carried in the record's
+   RDATA, which is a sequence of length-prefixed character-strings
+   [RFC1035].  A client reconstructs the certificate by concatenating
+   these character-strings in order, after removing the single length
+   octet that precedes each one.  A 124-byte classical certificate fits
+   in a single character-string, whereas a larger certificate spans
+   several character-strings that MUST be concatenated in this way
+   before the certificate is parsed.
+
    After receiving a set of certificates, the client checks their
    validity based on the current date, filters out the ones designed for
    encryption systems that are not supported by the client, and chooses