#
IETF conflict review for draft-smyshlyaev-mgm

conflict-review-smyshlyaev-mgm-00

Yes

No Objection

Francesca Palombini

Murray Kucherawy

Roman Danyliw

Zaheduzzaman Sarker

Éric Vyncke

(Alvaro Retana)

(Lars Eggert)

(Martin Duke)

(Robert Wilton)

**Note:** This ballot was opened for revision 00 and is now closed.

**Ballot question:** "Is this the correct conflict review response?"

Francesca Palombini

No Objection

Murray Kucherawy

No Objection

Roman Danyliw

No Objection

Zaheduzzaman Sarker

No Objection

Éric Vyncke

No Objection

Benjamin Kaduk Former IESG member

Yes

**Yes**(2021-03-31) Sent

Thank you to the authors for making this algorithm available in English! I believe there is sufficient detail included that I could implement the algorithm on top of the block cipher primitive (though I did not, and did not verify the test vectors). I only have some minor nit-level editorial comments about the document; no response to them is expected. NITS Section 3 (x) the transformation that maps two strings X = (x_{n-1}, ... , x_0) in V_n and Y = (y_{n-1}, ... , y_0) in V_n into the string Z = X (x) Y = (z_{n-1}, ... , z_0) in V_n; the string Z corresponds to the polynomial Z(w) = z_{n-1} * w^{n-1} + ... + z_1 * w + z_0 which is a result of the polynomials X(w) = x_{n-1} * w^{n-1} + ... + x_1 * w + x_0 and Y(w) = y_{n-1} * w^{n-1} + ... + y_1 * w + y_0 multiplication in the field GF(2^n), where n is the block size of the used block cipher; I think we want "which is the result of multiplying the polynomials X(w) [...] and Y(w) [...] in the field GF(2^n)" Section 4.1 In a very pedantic sense, the definitions for the decompositions of A and P into components is not properly defined for the case when there is less than a complete block of input, since the breakdowns assume there will be an A_1 (respectively, P_1) and equivalently that h-1 and q-1 are valid indices in the 1-indexed system. But it seems unlikely that anyone will actually be confused by the current formulation and I don't recommend any change. (Similarly for the decryption inputs.) can provide a string A of zero length. The length of the associated data A and of the plaintext P MUST be such that 0 < |A| + |P| < 2^{n/2}. It might be worth giving some reasoning for why it's forbidden to have an empty plaintext (with no additional data), since in some protocols it is useful to have an explicit authenticated "empty message" sentinel. Section 4.2 There's a little skew between the definition of A in §4.1 and here. The definite article looks fine to use here since there is a definite AAD associated with a given ciphertext, but the explicit condition "if |A| > 0, then" may be worth keeping. (Similarly for "If |C| > 0, then [...]".) 5. The authenticated tag T in V_S. Should this be "authenticated" or "authentication"? Section 5 I think "inverse-free" should be hyphenated in all instances. Availability of precomputations for the MGM means the possibility to calculate H_i and E_K(Y_i) even before data is retrieved. It is holds due to again the usage of counters for calculating them. s/It is holds due to again/It holds again due to/ Section 6 (side note) I expect the focus of new IETF work to be on nonce-misuse-resistant modes, but that in no way detracts from the value of having the MGM reference available in this form. I wonder if it is worth reiterating the requirement that |A| < 2^{n/2} and |P| < 2^{n/2} along with description of what fails if the limit is exceeded.

Alvaro Retana Former IESG member

No Objection

**No Objection**() Not sent

Lars Eggert Former IESG member

No Objection

**No Objection**() Not sent

Martin Duke Former IESG member

No Objection

**No Objection**() Not sent

Robert Wilton Former IESG member

No Objection

**No Objection**() Not sent