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

draft-irtf-cfrg-aead-limits.html

@@ -16,26 +16,26 @@
 in order to bound the advantage given to an attacker.  It considers limits in
 both single- and multi-key settings. 
     " name="description">
-<meta content="xml2rfc 3.18.2" name="generator">
+<meta content="xml2rfc 3.20.1" name="generator">
 <meta content="safe" name="keyword">
 <meta content="limits" name="keyword">
 <meta content="crypto" name="keyword">
 <meta content="draft-irtf-cfrg-aead-limits-latest" name="ietf.draft">
 <!-- Generator version information:
-  xml2rfc 3.18.2
-    Python 3.11.6
-    ConfigArgParse 1.5.3
+  xml2rfc 3.20.1
+    Python 3.11.8
+    ConfigArgParse 1.7
     google-i18n-address 3.1.0
     intervaltree 3.1.0
     Jinja2 3.1.2
     lxml 4.9.3
-    platformdirs 3.11.0
+    platformdirs 4.2.0
     pycountry 22.3.5
-    PyYAML 6.0
+    PyYAML 6.0.1
     requests 2.31.0
-    setuptools 67.7.2
+    setuptools 68.2.2
     six 1.16.0
-    wcwidth 0.2.8
+    wcwidth 0.2.13
 -->
 <link href="draft-irtf-cfrg-aead-limits.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
@@ -1034,11 +1034,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">AEAD Limits</td>
-<td class="right">October 2023</td>
+<td class="right">April 2024</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Günther, et al.</td>
-<td class="center">Expires 21 April 2024</td>
+<td class="center">Expires 3 October 2024</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1051,12 +1051,12 @@
 <dd class="internet-draft">draft-irtf-cfrg-aead-limits-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2023-10-19" class="published">19 October 2023</time>
+<time datetime="2024-04-01" class="published">1 April 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Informational</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2024-04-21">21 April 2024</time></dd>
+<dd class="expires"><time datetime="2024-10-03">3 October 2024</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1114,7 +1114,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 21 April 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 3 October 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1123,7 +1123,7 @@ <h2 id="name-copyright-notice">
 <a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
         </h2>
 <p id="section-boilerplate.2-1">
-            Copyright (c) 2023 IETF Trust and the persons identified as the
+            Copyright (c) 2024 IETF Trust and the persons identified as the
             document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.2-2">
             This document is subject to BCP 78 and the IETF Trust's Legal
@@ -1290,13 +1290,15 @@ <h2 id="name-introduction">
 parties. Any limits on the maximum length of inputs or encryption operations
 apply to that single key. The attacker's goal is to break security
 (confidentiality or integrity) of that specific key. However, in practice, there
-are often many users with independent keys. This multi-key security setting,
-often referred to as the multi-user setting in the academic literature,
-considers an attacker's advantage in breaking security of any of these many
-keys, further assuming the attacker may have done some offline work to help break
-security. As a result, AEAD algorithm limits may depend on offline work and the
-number of keys. However, given that a multi-key attacker does not target any specific
-key, acceptable advantages may differ from that of the single-key setting.<a href="#section-1-3" class="pilcrow">¶</a></p>
+are often many parties with independent keys, multiple sessions between two
+parties, and even many keys used within a single session due to rekeying. This
+multi-key security setting, often referred to as the multi-user setting in the
+academic literature, considers an attacker's advantage in breaking security of
+any of these many keys, further assuming the attacker may have done some offline
+work (measuring time, but not memory) to help break any key. As a result, AEAD
+algorithm limits may depend on offline work and the number of keys. However,
+given that a multi-key attacker does not target any specific key, acceptable
+advantages may differ from that of the single-key setting.<a href="#section-1-3" class="pilcrow">¶</a></p>
 <p id="section-1-4">The number of times a single pair of key and nonce can be used might also be
 relevant to security.  For some algorithms, such as AEAD_AES_128_GCM or
 AEAD_AES_256_GCM, this limit is 1 and using the same pair of key and nonce has
@@ -1305,17 +1307,18 @@ <h2 id="name-introduction">
 AEAD_AES_128_GCM_SIV can tolerate a limited amount of nonce reuse.<a href="#section-1-4" class="pilcrow">¶</a></p>
 <p id="section-1-5">It is good practice to have limits on how many times the same key (or pair of
 key and nonce) are used.  Setting a limit based on some measurable property of
-the usage, such as number of protected messages or amount of data transferred,
-ensures that it is easy to apply limits.  This might require the application of
-simplifying assumptions.  For example, TLS 1.3 and QUIC both specify limits on
-the number of records that can be protected, using the simplifying assumption
-that records are the same size; see <span><a href="https://rfc-editor.org/rfc/rfc8446#section-5.5" class="relref">Section 5.5</a> of [<a href="#TLS" class="cite xref">TLS</a>]</span> and <span><a href="https://rfc-editor.org/rfc/rfc9001#section-6.6" class="relref">Section 6.6</a> of [<a href="#RFC9001" class="cite xref">RFC9001</a>]</span>.<a href="#section-1-5" class="pilcrow">¶</a></p>
+the usage, such as number of protected messages, amount of data transferred, or
+time passed ensures that it is easy to apply limits.  This might require the
+application of simplifying assumptions.  For example, TLS 1.3 and QUIC both
+specify limits on the number of records that can be protected, using the
+simplifying assumption that records are the same size; see <span><a href="https://rfc-editor.org/rfc/rfc8446#section-5.5" class="relref">Section 5.5</a> of [<a href="#TLS" class="cite xref">TLS</a>]</span> and <span><a href="https://rfc-editor.org/rfc/rfc9001#section-6.6" class="relref">Section 6.6</a> of [<a href="#RFC9001" class="cite xref">RFC9001</a>]</span>.<a href="#section-1-5" class="pilcrow">¶</a></p>
 <p id="section-1-6">Exceeding the determined usage limit can be avoided using rekeying.  Rekeying
 uses a lightweight transform to produce new keys.  Rekeying effectively resets
 progress toward single-key limits, allowing a session to be extended without
 degrading security.  Rekeying can also provide a measure of forward and
 backward (post-compromise) security.  <span>[<a href="#RFC8645" class="cite xref">RFC8645</a>]</span> contains a thorough survey
-of rekeying and the consequences of different design choices.<a href="#section-1-6" class="pilcrow">¶</a></p>
+of rekeying and the consequences of different design choices.  When considering
+rekeying, the multi-user limits should be applied.<a href="#section-1-6" class="pilcrow">¶</a></p>
 <p id="section-1-7">Currently, AEAD limits and usage requirements are scattered among peer-reviewed
 papers, standards documents, and other RFCs. Determining the correct limits for
 a given setting is challenging as papers do not use consistent labels or
@@ -1397,7 +1400,7 @@ <h2 id="name-notation">
           </tr>
           <tr>
             <td class="text-right" rowspan="1" colspan="1">o</td>
-            <td class="text-left" rowspan="1" colspan="1">Offline adversary work (in number of encryption and decryption queries; multi-key setting only)</td>
+            <td class="text-left" rowspan="1" colspan="1">Offline adversary work (time, measured in number of encryption and decryption queries; multi-key setting only)</td>
           </tr>
           <tr>
             <td class="text-right" rowspan="1" colspan="1">u</td>

draft-irtf-cfrg-aead-limits.txt

@@ -5,10 +5,10 @@
 Network Working Group                                         F. Günther
 Internet-Draft                              IBM Research Europe - Zurich
 Intended status: Informational                                M. Thomson
-Expires: 21 April 2024                                           Mozilla
+Expires: 3 October 2024                                          Mozilla
                                                               C. A. Wood
                                                               Cloudflare
-                                                         19 October 2023
+                                                            1 April 2024
 
 
                     Usage Limits on AEAD Algorithms
@@ -50,11 +50,11 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 21 April 2024.
+   This Internet-Draft will expire on 3 October 2024.
 
 Copyright Notice
 
-   Copyright (c) 2023 IETF Trust and the persons identified as the
+   Copyright (c) 2024 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
@@ -124,15 +124,17 @@ Table of Contents
    between two parties.  Any limits on the maximum length of inputs or
    encryption operations apply to that single key.  The attacker's goal
    is to break security (confidentiality or integrity) of that specific
-   key.  However, in practice, there are often many users with
-   independent keys.  This multi-key security setting, often referred to
-   as the multi-user setting in the academic literature, considers an
-   attacker's advantage in breaking security of any of these many keys,
-   further assuming the attacker may have done some offline work to help
-   break security.  As a result, AEAD algorithm limits may depend on
-   offline work and the number of keys.  However, given that a multi-key
-   attacker does not target any specific key, acceptable advantages may
-   differ from that of the single-key setting.
+   key.  However, in practice, there are often many parties with
+   independent keys, multiple sessions between two parties, and even
+   many keys used within a single session due to rekeying.  This multi-
+   key security setting, often referred to as the multi-user setting in
+   the academic literature, considers an attacker's advantage in
+   breaking security of any of these many keys, further assuming the
+   attacker may have done some offline work (measuring time, but not
+   memory) to help break any key.  As a result, AEAD algorithm limits
+   may depend on offline work and the number of keys.  However, given
+   that a multi-key attacker does not target any specific key,
+   acceptable advantages may differ from that of the single-key setting.
 
    The number of times a single pair of key and nonce can be used might
    also be relevant to security.  For some algorithms, such as
@@ -145,20 +147,21 @@ Table of Contents
    It is good practice to have limits on how many times the same key (or
    pair of key and nonce) are used.  Setting a limit based on some
    measurable property of the usage, such as number of protected
-   messages or amount of data transferred, ensures that it is easy to
-   apply limits.  This might require the application of simplifying
-   assumptions.  For example, TLS 1.3 and QUIC both specify limits on
-   the number of records that can be protected, using the simplifying
-   assumption that records are the same size; see Section 5.5 of [TLS]
-   and Section 6.6 of [RFC9001].
+   messages, amount of data transferred, or time passed ensures that it
+   is easy to apply limits.  This might require the application of
+   simplifying assumptions.  For example, TLS 1.3 and QUIC both specify
+   limits on the number of records that can be protected, using the
+   simplifying assumption that records are the same size; see
+   Section 5.5 of [TLS] and Section 6.6 of [RFC9001].
 
    Exceeding the determined usage limit can be avoided using rekeying.
    Rekeying uses a lightweight transform to produce new keys.  Rekeying
    effectively resets progress toward single-key limits, allowing a
    session to be extended without degrading security.  Rekeying can also
    provide a measure of forward and backward (post-compromise) security.
    [RFC8645] contains a thorough survey of rekeying and the consequences
-   of different design choices.
+   of different design choices.  When considering rekeying, the multi-
+   user limits should be applied.
 
    Currently, AEAD limits and usage requirements are scattered among
    peer-reviewed papers, standards documents, and other RFCs.
@@ -184,39 +187,41 @@ Table of Contents
    This document defines limitations in part using the quantities in
    Table 1 below.
 
-       +========+=================================================+
-       | Symbol | Description                                     |
-       +========+=================================================+
-       |      n | AEAD block length (in bits)                     |
-       +--------+-------------------------------------------------+
-       |      k | AEAD key length (in bits)                       |
-       +--------+-------------------------------------------------+
-       |      r | AEAD nonce length (in bits)                     |
-       +--------+-------------------------------------------------+
-       |      t | Size of the authentication tag (in bits)        |
-       +--------+-------------------------------------------------+
-       |      L | Maximum length of each message, including both  |
-       |        | plaintext and AAD (in blocks)                   |
-       +--------+-------------------------------------------------+
-       |      s | Total plaintext length in all messages (in      |
-       |        | blocks)                                         |
-       +--------+-------------------------------------------------+
-       |      q | Number of protected messages (AEAD encryption   |
-       |        | invocations)                                    |
-       +--------+-------------------------------------------------+
-       |      v | Number of attacker forgery attempts (failed     |
-       |        | AEAD decryption invocations + 1)                |
-       +--------+-------------------------------------------------+
-       |      p | Upper bound on adversary attack probability     |
-       +--------+-------------------------------------------------+
-       |      o | Offline adversary work (in number of encryption |
-       |        | and decryption queries; multi-key setting only) |
-       +--------+-------------------------------------------------+
-       |      u | Number of keys (multi-key setting only)         |
-       +--------+-------------------------------------------------+
-       |      B | Maximum number of blocks encrypted by any key   |
-       |        | (multi-key setting only)                        |
-       +--------+-------------------------------------------------+
+          +========+===========================================+
+          | Symbol | Description                               |
+          +========+===========================================+
+          |      n | AEAD block length (in bits)               |
+          +--------+-------------------------------------------+
+          |      k | AEAD key length (in bits)                 |
+          +--------+-------------------------------------------+
+          |      r | AEAD nonce length (in bits)               |
+          +--------+-------------------------------------------+
+          |      t | Size of the authentication tag (in bits)  |
+          +--------+-------------------------------------------+
+          |      L | Maximum length of each message, including |
+          |        | both plaintext and AAD (in blocks)        |
+          +--------+-------------------------------------------+
+          |      s | Total plaintext length in all messages    |
+          |        | (in blocks)                               |
+          +--------+-------------------------------------------+
+          |      q | Number of protected messages (AEAD        |
+          |        | encryption invocations)                   |
+          +--------+-------------------------------------------+
+          |      v | Number of attacker forgery attempts       |
+          |        | (failed AEAD decryption invocations + 1)  |
+          +--------+-------------------------------------------+
+          |      p | Upper bound on adversary attack           |
+          |        | probability                               |
+          +--------+-------------------------------------------+
+          |      o | Offline adversary work (time, measured in |
+          |        | number of encryption and decryption       |
+          |        | queries; multi-key setting only)          |
+          +--------+-------------------------------------------+
+          |      u | Number of keys (multi-key setting only)   |
+          +--------+-------------------------------------------+
+          |      B | Maximum number of blocks encrypted by any |
+          |        | key (multi-key setting only)              |
+          +--------+-------------------------------------------+
 
                             Table 1: Notation