Editorial comments

[agievich]

1. Section 2:

   MUST, MUST NOT, REQUIRED,...

First, not all of these words are used. Second, it seems that the draft should avoid imperative words. The draft is about properties not requirements.

2. Section 3:

   An AEAD algorithm is defined by two operations...

It seems that "operations" is not the most appropriate word here, "subalgorithms..." or "operations (subalgorithms)..." would be better.

3. Section 3:

   Throughout this document, by default, we will consider the authentication tag as part of the ciphertext unless stated otherwise.

It seems that "unless stated otherwise" doesn't work.

4. Paragraph 4.2.2:

   An AEAD algorithm guarantees that the ciphertext and the associated data have not been changed or forged by an active, nonce-respecting adversary.

An algorithm cannot guarantee the absence of integrity violations. It can only detect the violations.

5. Paragraph 4.2.3:

   An AEAD algorithm provides confidentiality and data integrity...

An algorithm cannot provide "integrity", only "integrity control".

6. Paragraph 4.3.7:

   Nonce misuse resilience: Security is provided only for messages encrypted with fresh nonces (correctly encrypted messages).

The definition has a negative connotation ("is provided only for") and can hardly be interpreted as a positive property. The definition can be reformulated as follows:

Security is provided for all messages that were encrypted with non-repeated (fresh) nonces.

7. Paragraph 4.4.2:

   without evaluating the inverse of that primitive.

It is not mathematically strong enough: "evaluating the inverse" of E_K can be read as constructing E_K^{-1}. A possible fix: "without calls to the inverse of that primitive".

8. Section 5: "game-based security notion" vs "indifferentiability framework [BM18]".

The dichotomy doesn't seem correct. At least because games are used in [BM18]. It seems that "game-based security notion" is not the best term here, it can be interpreted in very different ways.

[AndAlBo]

Hi Sergey,

Thanks a lot for your comments! I've addressed most of them in the latest version. Please find some notes below.

1. In addition to just listing properties, we also aim (as outlined in the scope of the document) to make the usage of corresponding terms uniform across other future documents. In that respect, we provide some requirements on how to use the terms.

I'm not sure whether it is required to list only the key terms used in the document or all of them. I think the RFC Editor will clarify that.

2. I tend to agree with you. However, since "operations" is used in RFC 5116, I prefer to maintain that terminology in the draft.

3. It seems that "unless stated otherwise" doesn't work.

Indeed, it doesn't. I have removed it.

4. An algorithm cannot guarantee the absence of integrity violations. It can only detect the violations.

I agree. I have rewritten the definition accordingly.

5. With the improved definition of data integrity (in the context of AEAD algorithms), I believe the definition is now clear.

6. can hardly be interpreted as a positive property

Totally agree! I’ve reformulated it.

7. One of the easiest yet most challenging definitions! Reformulated it as you proposed.

8. I find (and this is implicitly confirmed by other reviews) that the understanding of these terms is fairly well established, and in the AEAD context, it is clear. Additionally, this dichotomy is used in [BM12].

[agievich]

Hi Andrey,

Thanks for the feedback. I agree with you on all points except the first and last. Of course, this is very subjective. At your discretion as an editor.

1

In addition to just listing properties, we also aim (as outlined in the scope of the document) to make the usage of corresponding terms uniform across other future documents. In that respect, we provide some requirements on how to use the terms.

It seems that imperative keywords refer to AEAD algorithms and supporting documentation, not to terms.

Examples (with MUST):

Each nonce value MUST be unique in every distinct invocation of the operation for any particular value of the key.

In such cases, an AEAD algorithm is said to provide full commitment in a restricted setting. The imposed restrictions MUST be listed.

Every claimed security property of an AEAD algorithm MUST undergo security analysis within a relevant notion. ... If an alternative notion is used, there MUST exist proof of equivalence or it SHOULD be indicated that a non-equivalent notion is used.

It is quite surprising for me to find imperative words in the text that positions itself as informative (see Abstract and Scope). A simple solution is to lower the register of imperative words. A more subtle way is to rewrite the imperative sentences in a descriptive style. For example,

Each nonce value is unique in every distinct invocation of the operation for any particular value of the key.

8

I find (and this is implicitly confirmed by other reviews) that the understanding of these terms is fairly well established, and in the AEAD context, it is clear. Additionally, this dichotomy is used in [BM12].

I cannot find [BM12] in the text. Do you mean [BM18]?

Notice that [BM18] uses "game-based formulation" when defining "indifferentiability composition" (see Theorem 1). This only confirms my point that the "game-based vs indifferentiability" dichotomy is questionable.

A possible solution here is to replace "game-based (notion)" with "provable security (notion)". Since "indifferentiability framework" is a part of "provable security" we can avoid mentioning it.