Script updating gh-pages from 0aeee5b. [ci skip]

draft-venhoek-nts-pool.html

@@ -7,6 +7,7 @@
 <title>NTS extensions for enabling pools</title>
 <meta content="David Venhoek" name="author">
 <meta content="Folkert de Vries" name="author">
+<meta content="Marc Schoolderman" name="author">
 <meta content="
        The aim of this document is to describe a proof of concept system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple downstream servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. 
     " name="description">
@@ -1030,7 +1031,7 @@
 <td class="right">December 2023</td>
 </tr></thead>
 <tfoot><tr>
-<td class="left">Venhoek &amp; Vries</td>
+<td class="left">Venhoek, et al.</td>
 <td class="center">Expires 23 June 2024</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
@@ -1060,6 +1061,10 @@
       <div class="author-name">F. D. Vries</div>
 <div class="org">Tweede golf B.V.</div>
 </div>
+<div class="author">
+      <div class="author-name">M. Schoolderman</div>
+<div class="org">Tweede golf B.V.</div>
+</div>
 </dd>
 </dl>
 </div>
@@ -1270,7 +1275,7 @@ <h3 id="name-keep-alive">
 Critical bit: 0<a href="#section-6.1-1" class="pilcrow">¶</a></p>
 <p id="section-6.1-2">Indicates a desire to keep the TLS connection active for more than one message exchange. This can be used by a pool to reuse connections to downstream NTS Key Exchange servers multiple times, reducing load on both the pool and downstream servers.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
 <p id="section-6.1-3">Client <span class="bcp14">MUST</span> send this record with a body of size 0. Client <span class="bcp14">MUST NOT</span> use Keep Alive unless the request contains a record type allowing the use of Keep Alive. Within this specification, that is limited to the Supported Protocol List and Fixed Key Request records. A server <span class="bcp14">SHOULD</span> ignore any body for the Keep Alive record.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
-<p id="section-6.1-4">When supported by server and allowed for the request in question, the server <span class="bcp14">MUST</span> include a Keep Alive record with a body of size 0 in the response and keep the TLS connection active after the response to handle further requests from the client. A client <span class="bcp14">SHOULD</span> ignore any body for the Keep Alive record.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
+<p id="section-6.1-4">When supported by a server and allowed for the request in question, the server <span class="bcp14">MUST</span> include a Keep Alive record with a body of size 0 in the response and keep the TLS connection active after the response to handle further requests from the client. A client <span class="bcp14">SHOULD</span> ignore any body for the Keep Alive record.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
 <p id="section-6.1-5">When included in the request or response, the client respectively server <span class="bcp14">MAY</span>, contrary to the requirements in <span>[<a href="#RFC8915" class="cite xref">RFC8915</a>]</span>, send another request or response. Any TLS "close_notify" <span class="bcp14">SHALL</span> be sent only after the last request or response respectively to use the connection.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
 <p id="section-6.1-6">Once a Keep Alive record has been sent by a client, or honored by a server, the TLS connection over which it was sent <span class="bcp14">MUST NOT</span> be used for key extraction. Doing so anyway can result in the reuse of keys and may result in loss of confidentiality or authenticity of the resulting NTP exchanges.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
 </section>
@@ -1309,7 +1314,7 @@ <h3 id="name-fixed-key-request">
         </h3>
 <p id="section-6.4-1">Record Type Number: To be assigned by IANA (draft implementations: 0x4002)
 Critical Bit: 1<a href="#section-6.4-1" class="pilcrow">¶</a></p>
-<p id="section-6.4-2">When client is properly authenticated, the server <span class="bcp14">SHOULD NOT</span> perform Key Extraction but rather use the keys provided by the client in the extension field. This allows a pool to do key negotiation on behalf of its users with the downstream NTS Key Exchange servers, even though it terminates the TLS connection.<a href="#section-6.4-2" class="pilcrow">¶</a></p>
+<p id="section-6.4-2">When a client is properly authenticated, the server <span class="bcp14">SHOULD NOT</span> perform Key Extraction but rather use the keys provided by the client in the extension field. This allows a pool to do key negotiation on behalf of its users with the downstream NTS Key Exchange servers, even though it terminates the TLS connection.<a href="#section-6.4-2" class="pilcrow">¶</a></p>
 <p id="section-6.4-3">When used, the client <span class="bcp14">MUST</span> provide an AEAD Algorithm Negotiation record with precisely one algorithm, and a Next Protocol Negotiation record with precisely one next protocol. The data in the Fixed Key Request record must have length twice the key length N of the AEAD algorithm in the AEAD Algorithm Negotiation record. The first N bytes <span class="bcp14">MUST</span> be the C2S Key and the second set of N bytes <span class="bcp14">MUST</span> be the S2C key. Clients <span class="bcp14">MAY</span> use Keep Alive in combination with this record.<a href="#section-6.4-3" class="pilcrow">¶</a></p>
 <p id="section-6.4-4"><span class="bcp14">MUST NOT</span> be sent by a server. Server <span class="bcp14">SHOULD</span> treat the extension field as unknown when sent by any client not authorized to make fixed key requests.<a href="#section-6.4-4" class="pilcrow">¶</a></p>
 </section>
@@ -1348,7 +1353,7 @@ <h3 id="name-pools-position">
         <h3 id="name-error-handling">
 <a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-error-handling" class="section-name selfRef">Error handling</a>
         </h3>
-<p id="section-7.2-1">To avoid giving multiple downstream time sources access to the key material of the end user, it is important that the keys extracted from the TLS session between the user and the pool are sent to at most one downstream time source. If an error occurs after sending the Fixed Key Request record, either with the TLS connection between the pool and the downstream time source, or by being explicitly reported by the downstream time source to the pool, the pool <span class="bcp14">SHOULD</span> return an error to the user. Retrying with a different downstream time source may unintentionally leave the user vulnerable to the operator of the originally selected downstream time source.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
+<p id="section-7.2-1">To avoid giving multiple downstream time sources access to the key material of the end user, it is important that the keys extracted from the TLS session between the user and the pool are sent to at most one downstream time source. If an error occurs after sending the Fixed Key Request record, either with the TLS connection between the pool and the downstream time source, or by being explicitly reported by the downstream time source to the pool, the pool <span class="bcp14">SHOULD</span> return an error to the user. Retrying with a different downstream time source during the same TLS session may unintentionally leave the user vulnerable to the operator of the originally selected downstream time source.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -1475,6 +1480,14 @@ <h2 id="name-authors-addresses">
 <a href="mailto:[email protected]" class="email">[email protected]</a>
 </div>
 </address>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Marc Schoolderman</span></div>
+<div dir="auto" class="left"><span class="org">Tweede golf B.V.</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:[email protected]" class="email">[email protected]</a>
+</div>
+</address>
 </section>
 </div>
 <script>const toc = document.getElementById("toc");

draft-venhoek-nts-pool.txt

@@ -4,8 +4,9 @@
 
 ntp                                                           D. Venhoek
 Internet-Draft                                               F. D. Vries
-Intended status: Standards Track                        Tweede golf B.V.
-Expires: 23 June 2024                                   21 December 2023
+Intended status: Standards Track                         M. Schoolderman
+Expires: 23 June 2024                                   Tweede golf B.V.
+                                                        21 December 2023
 
 
                    NTS extensions for enabling pools
@@ -187,9 +188,9 @@ Table of Contents
    Supported Protocol List and Fixed Key Request records.  A server
    SHOULD ignore any body for the Keep Alive record.
 
-   When supported by server and allowed for the request in question, the
-   server MUST include a Keep Alive record with a body of size 0 in the
-   response and keep the TLS connection active after the response to
+   When supported by a server and allowed for the request in question,
+   the server MUST include a Keep Alive record with a body of size 0 in
+   the response and keep the TLS connection active after the response to
    handle further requests from the client.  A client SHOULD ignore any
    body for the Keep Alive record.
 
@@ -257,11 +258,11 @@ Table of Contents
    Record Type Number: To be assigned by IANA (draft implementations:
    0x4002) Critical Bit: 1
 
-   When client is properly authenticated, the server SHOULD NOT perform
-   Key Extraction but rather use the keys provided by the client in the
-   extension field.  This allows a pool to do key negotiation on behalf
-   of its users with the downstream NTS Key Exchange servers, even
-   though it terminates the TLS connection.
+   When a client is properly authenticated, the server SHOULD NOT
+   perform Key Extraction but rather use the keys provided by the client
+   in the extension field.  This allows a pool to do key negotiation on
+   behalf of its users with the downstream NTS Key Exchange servers,
+   even though it terminates the TLS connection.
 
    When used, the client MUST provide an AEAD Algorithm Negotiation
    record with precisely one algorithm, and a Next Protocol Negotiation
@@ -329,8 +330,9 @@ Table of Contents
    the pool and the downstream time source, or by being explicitly
    reported by the downstream time source to the pool, the pool SHOULD
    return an error to the user.  Retrying with a different downstream
-   time source may unintentionally leave the user vulnerable to the
-   operator of the originally selected downstream time source.
+   time source during the same TLS session may unintentionally leave the
+   user vulnerable to the operator of the originally selected downstream
+   time source.
 
 8.  IANA Considerations
 
@@ -399,3 +401,8 @@ Authors' Addresses
    Folkert de Vries
    Tweede golf B.V.
    Email: [email protected]
+
+
+   Marc Schoolderman
+   Tweede golf B.V.
+   Email: [email protected]

index.html

@@ -53,7 +53,7 @@ <h2>Preview for branch <a href="marc-patch-1">marc-patch-1</a></h2>
       <tr>
         <td><a href="marc-patch-1/draft-venhoek-nts-pool.html" class="html draft-venhoek-nts-pool" title="NTS extensions for enabling pools (HTML)">NTS pools</a></td>
         <td><a href="marc-patch-1/draft-venhoek-nts-pool.txt" class="txt draft-venhoek-nts-pool" title="NTS extensions for enabling pools (Text)">plain text</a></td>
-        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://pendulum-project.github.io/nts-pool-draft/draft-venhoek-nts-pool.txt&amp;url_2=https://pendulum-project.github.io/nts-pool-draft/marc-patch-1/draft-venhoek-nts-pool.txt" class="diff draft-venhoek-nts-pool">diff with main</a></td>
+        <td>same as main</td>
       </tr>
     </table>
     <script>