IETF conflict review for draft-irtf-cfrg-argon2
conflict-review-irtf-cfrg-argon2-00

The following approval message was sent
From: The IESG
To: Colin Perkins ,
    cfrg-chairs@ietf.org,
    draft-irtf-cfrg-argon2@ietf.org,
    Alexey Melnikov ,
    irtf-chair@irtf.org,
    Internet Research Steering Group
Cc: iana@iana.org,
    The IESG ,
    IETF-Announce
Subject: Results of IETF-conflict review for draft-irtf-cfrg-argon2-12

The IESG has completed a review of draft-irtf-cfrg-argon2-12 consistent with
RFC5742.

The IESG has no problem with the publication of 'The memory-hard Argon2
password hash and proof-of-work function'  as
an Informational RFC.

The IESG has concluded that there is no conflict between this document and
IETF work.

The IESG would also like the IRTF to review the comments in the datatracker
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot and
the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-argon2/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/

The process for such documents is described in RFC 5743

Thank you,

The IESG Secretary

[Ballot comment]
I'm happy to see this published as an RFC for use in IETF protocols!

A few minor (editorial) notes that may be of use to the authors follow.

[obligatory note that RFC 8174 provides an updated version of the BCP 14
boilerplate that fixes an erratum in the RFC 2119 boilerplate]

Section 3.1

  o  Nonce S, which is a salt for password hashing applications.  MUST
      have length not greater than 2^(32)-1 bytes.  16 bytes is
      RECOMMENDED for password hashing.  Salt SHOULD be unique for each
      password.

(nits) Probably s/Salt/S/, and it's surprising to see "length not
greater than 2^(32)-1 bytes" in this point but "length from 0 to 2^(32)
- 1 bytes" when they (IIUC) convey the same requirement on length.  (The
"not greater than" formulation is used several more times, later.)

Section 3.2

  with x being its output length in bytes.  Here H^x() applied to
  string A is the BLAKE2b [BLAKE2] function, which takes
  (d,|dd|,kk=0,nn=x) as parameters where d is A padded to a multiple of
  128 bytes and partitioned into 128-byte blocks.  [...]

Is "|dd|" a typo?  I don't see 'dd' anywhere else in the document
(though it is used internally in [BLAKE2]).

Section 3.4.1.2

I see "LE64(s)" in the expression but the caption discusses "sl", the
slice number.  I suspect the expression should use "LE64(sl)".

Section 3.5

I wonder if the phrase "row-major order" would be useful in describing
the matrix layout.  (Perhaps not, as the current description is
unambiguous to a careful reader.)