page 3 (section 1): "four inputs -- secret key, nonce, plaintext,
associated data (of which plaintext and associated data can optionally
be zero-length)" -> RFC 5116 also allows the nonce to be zero-length
(though it mandates, in that case, that the nonce must always be
zero-length). (At the end of section 4, on page 8, it is explained that
schemes with repeated nonce values, which cover the extreme case of no
nonce at all, are out of scope of the document; this might be said
earlier in the document)
page 5 (table 1): the table talks about the AEAD "block length" but no
notion of what a block could be has been introduced at this point. In
fact, blocks are not really defined anywhere in the document; each
scheme-specific section indicates a block size without explaining where
it comes from. In some cases it is even ambiguous, e.g. in the case of
ChaCha20+Poly1305 where ChaCha20 generates pseudorandom data in blocks
of 512 bits, but Poly1305 consumes blocks of 128 bits.
page 5 (section 3): "passive attacker" and "active attacker" -> the use
of "passive" and "active" terms seems at bit at odds with the usual
acceptions. Traditionally, a passive attacker only observes but does not
otherwise interact with the attacked system; the important distinction
is that a number of contextual mitigations can thwart active attackers
(e.g. the attacker's requests may show up in logs and traffic metrics),
contrary to passive attackers. Here, an attacker who can submit chosen
plaintexts is considered "passive", which substantially differs from the
usual terminology. The linked references ([AEComposition], [AEAD]) do
not use the terms "active" or "passive".
I think the source of the use of "passive" here is that in order to
analyze the security of a non-interacting attacker who only observes
plaintext/ciphertext pairs, then we have to make some assumptions on the
format of the plaintexts, which depends on the usage context. To ease
analysis, we then assume that the honest user is encrypting exactly the
plaintexts that would most favour the attacker: we make a worst case
assumption of the defender doing (unwittingly) the attacker's job and
thus turning the passive (non-interacting) model into a chosen-plaintext
attack model. I.e. we look at the non-interacting situation by stating
that it cannot be worse than an interacting chosen-plaintext situation,
and it is the latter which we really study.
Since the words "active" and "passive" appear only in section 3 but not
in the rest of the document, I suggest rewording the text to remove them
altogether; the more common and accurate terminology is
"chosen-plaintext attacks" and "chosen-ciphertext attacks".
page 9 (section 5.1): "t = 128 [GCM]" -> the [GCM] document (NIST SP
800-38D) actually specifies tags of 128, 120, 112, 104, 96, 64 or 32
bits (with some extra usage conditions for the 32-bit and 64-bit tags).
It is RFC 5116 which further constrains the tag size to be exactly 128
bits, and no other size.
page 9 (section 5.2): For ChaCha20+Poly1305, the first paragraph defines
that n = 512 (i.e. the ChaCha20 blocks), but within the same sentence
proceeds to express the lengths of AAD and plaintext "in blocks of 128
bits", which is quite confusing.
page 10 (section 5.2.1): "CA <= 0" -> this is of course not true,
strictly speaking; the confidentiality advantage was defined (in section
3) as the probability of an attacker distinguishing the ciphertext from
a random function output, which the attacker can always do with a very
small but non-zero probability through guessing the key. What the
document wants to say here is that the success probability of the
attacker is negligible, or, more precisely, that "guess the key" is the
best attack under the assumption that ChaCha20 has PRF security, and
chosen plaintext or ciphertext attacks do not improve the attacker's
advantage as long as the number of plaintext/ciphertext pairs remains
below the birthday bound, which is ludicrously large for ChaCha20 thanks
to its 512-bit blocks.
page 13 (section 6.1): "k = 128 or k = 256 for AEAD_AES_128_GCM and
AEAD_AES_128_GCM respectively" -> the second "AEAD_AES_128_GCM" should
be "AEAD_AES_256_GCM".
page 15 (section 6.2.2): "CA <= (o + q) / 2^247)" -> there's a spurious
closing parenthesis at the end.
page 17 (section 7): "In particular, in two-party communication, one
participant cannot regard apparent overuse of a key by other
participants as being in error, when it could be that the other
participant has better information about bounds." -> This strikes me as
a somewhat dangerous advice; it somehow reads as: "you shall not use
your decryption key for more than q messages because allowing so would
be unsafe, but if you have more than q messages to decrypt, well, go for
it, after all who knows, it's probably fine". I am pretty sure some
standardization bodies (e.g. NIST) would frown upon that. If there is a
limit on decryption attempts, but implementations don't enforce it, then
it's not a limit; it's just a commentary.
It is true that bounds may be revised and some usages that were
considered potentially unsafe could turn out to be safe after all (and
the converse may also happen!). However, there is a different between
accepting that implementations may have to be updated to account for new
scientific results, and dynamically assuming that the other party
knows best even if no local update was applied.
page 20 (acknowledgments): the document thanks "Scott Flurer", and while
I cannot dismiss the possiblity that somebody called Flurer provided
input to the document, I must say that it might have been the well-known
cryptographer "Scott Fluhrer", with an extra "h".
page 3 (section 1): "four inputs -- secret key, nonce, plaintext, associated data (of which plaintext and associated data can optionally be zero-length)" -> RFC 5116 also allows the nonce to be zero-length (though it mandates, in that case, that the nonce must always be zero-length). (At the end of section 4, on page 8, it is explained that schemes with repeated nonce values, which cover the extreme case of no nonce at all, are out of scope of the document; this might be said earlier in the document)
page 5 (table 1): the table talks about the AEAD "block length" but no notion of what a block could be has been introduced at this point. In fact, blocks are not really defined anywhere in the document; each scheme-specific section indicates a block size without explaining where it comes from. In some cases it is even ambiguous, e.g. in the case of ChaCha20+Poly1305 where ChaCha20 generates pseudorandom data in blocks of 512 bits, but Poly1305 consumes blocks of 128 bits.
page 5 (section 3): "passive attacker" and "active attacker" -> the use of "passive" and "active" terms seems at bit at odds with the usual acceptions. Traditionally, a passive attacker only observes but does not otherwise interact with the attacked system; the important distinction is that a number of contextual mitigations can thwart active attackers (e.g. the attacker's requests may show up in logs and traffic metrics), contrary to passive attackers. Here, an attacker who can submit chosen plaintexts is considered "passive", which substantially differs from the usual terminology. The linked references ([AEComposition], [AEAD]) do not use the terms "active" or "passive".
I think the source of the use of "passive" here is that in order to analyze the security of a non-interacting attacker who only observes plaintext/ciphertext pairs, then we have to make some assumptions on the format of the plaintexts, which depends on the usage context. To ease analysis, we then assume that the honest user is encrypting exactly the plaintexts that would most favour the attacker: we make a worst case assumption of the defender doing (unwittingly) the attacker's job and thus turning the passive (non-interacting) model into a chosen-plaintext attack model. I.e. we look at the non-interacting situation by stating that it cannot be worse than an interacting chosen-plaintext situation, and it is the latter which we really study.
Since the words "active" and "passive" appear only in section 3 but not in the rest of the document, I suggest rewording the text to remove them altogether; the more common and accurate terminology is "chosen-plaintext attacks" and "chosen-ciphertext attacks".
page 9 (section 5.1): "t = 128 [GCM]" -> the [GCM] document (NIST SP 800-38D) actually specifies tags of 128, 120, 112, 104, 96, 64 or 32 bits (with some extra usage conditions for the 32-bit and 64-bit tags). It is RFC 5116 which further constrains the tag size to be exactly 128 bits, and no other size.
page 9 (section 5.2): For ChaCha20+Poly1305, the first paragraph defines that n = 512 (i.e. the ChaCha20 blocks), but within the same sentence proceeds to express the lengths of AAD and plaintext "in blocks of 128 bits", which is quite confusing.
page 10 (section 5.2.1): "CA <= 0" -> this is of course not true, strictly speaking; the confidentiality advantage was defined (in section 3) as the probability of an attacker distinguishing the ciphertext from a random function output, which the attacker can always do with a very small but non-zero probability through guessing the key. What the document wants to say here is that the success probability of the attacker is negligible, or, more precisely, that "guess the key" is the best attack under the assumption that ChaCha20 has PRF security, and chosen plaintext or ciphertext attacks do not improve the attacker's advantage as long as the number of plaintext/ciphertext pairs remains below the birthday bound, which is ludicrously large for ChaCha20 thanks to its 512-bit blocks.
page 13 (section 6.1): "k = 128 or k = 256 for AEAD_AES_128_GCM and AEAD_AES_128_GCM respectively" -> the second "AEAD_AES_128_GCM" should be "AEAD_AES_256_GCM".
page 15 (section 6.2.2): "CA <= (o + q) / 2^247)" -> there's a spurious closing parenthesis at the end.
page 17 (section 7): "In particular, in two-party communication, one participant cannot regard apparent overuse of a key by other participants as being in error, when it could be that the other participant has better information about bounds." -> This strikes me as a somewhat dangerous advice; it somehow reads as: "you shall not use your decryption key for more than q messages because allowing so would be unsafe, but if you have more than q messages to decrypt, well, go for it, after all who knows, it's probably fine". I am pretty sure some standardization bodies (e.g. NIST) would frown upon that. If there is a limit on decryption attempts, but implementations don't enforce it, then it's not a limit; it's just a commentary.
It is true that bounds may be revised and some usages that were considered potentially unsafe could turn out to be safe after all (and the converse may also happen!). However, there is a different between accepting that implementations may have to be updated to account for new scientific results, and dynamically assuming that the other party knows best even if no local update was applied.
page 20 (acknowledgments): the document thanks "Scott Flurer", and while I cannot dismiss the possiblity that somebody called Flurer provided input to the document, I must say that it might have been the well-known cryptographer "Scott Fluhrer", with an extra "h".