IETF conflict review for draft-irtf-cfrg-argon2
conflict-review-irtf-cfrg-argon2-00
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-10-26
|
00 | Amy Vezza | The following approval message was sent From: The IESG To: Colin Perkins , cfrg-chairs@ietf.org, draft-irtf-cfrg-argon2@ietf.org, Alexey Melnikov … 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 |
2020-10-26
|
00 | Amy Vezza | IESG has approved the conflict review response |
2020-10-26
|
00 | Amy Vezza | Closed "Approve" ballot |
2020-10-26
|
00 | Amy Vezza | Conflict Review State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent |
2020-10-22
|
00 | Cindy Morgan | Conflict Review State changed to Approved No Problem - announcement to be sent from IESG Evaluation |
2020-10-22
|
00 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-10-22
|
00 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-10-21
|
00 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-10-21
|
00 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-10-21
|
00 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-10-21
|
00 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-10-20
|
00 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-10-20
|
00 | Benjamin Kaduk | [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 … [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.) |
2020-10-20
|
00 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2020-10-20
|
00 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-10-20
|
00 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-10-19
|
00 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-10-19
|
00 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2020-10-15
|
00 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2020-10-15
|
00 | Roman Danyliw | Created "Approve" ballot |
2020-10-15
|
00 | Roman Danyliw | Conflict Review State changed to IESG Evaluation from AD Review |
2020-10-15
|
00 | Roman Danyliw | Placed on agenda for telechat - 2020-10-22 |
2020-10-15
|
00 | Roman Danyliw | New version available: conflict-review-irtf-cfrg-argon2-00.txt |
2020-09-09
|
00 | Alissa Cooper | Conflict Review State changed to AD Review from Needs Shepherd |
2020-09-09
|
00 | Alissa Cooper | Shepherding AD changed to Roman Danyliw |
2020-09-09
|
00 | Alissa Cooper | Removed from agenda for telechat |
2020-09-08
|
00 | Cindy Morgan | Placed on agenda for telechat - 2020-09-10 |
2020-09-08
|
00 | Colin Perkins | IETF conflict review requested |