Re: [Cfrg] Fwd: Rev RFC 7539?

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

To answer one minor point: yes we do want C code (that can run and produce measurable output regardless of ‎the level of understanding of those who compile it :) rather that (or at worst - in addition to) pseudocode that people were known to interpret and implement wrongly now and then.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Stanislav V. Smyshlyaev
Sent: Thursday, January 19, 2017 05:50
To: IRTF CFRG
Subject: Re: [Cfrg] Fwd: Rev RFC 7539?

Document: draft-nir-cfrg-rfc7539bis-00
Reviewer: Stanislav Smyshlyaev
Review Date: 2017-01-19

The purpose of the document is to address a set of of errata for RFC 7539. It has been done systematically and correctly - all errata have been addressed.

RFC 7539 is an extremely important document providing some (optional/"standby") diversity, so, I totally support the work and the adoption of the new rfc7539bis as a CFRG document.

My only concerns related to the changes are the following (these two have already been spotted by Russ Housley and John Mattsson):
- there are no changes in the Security Considerations section, while the abstract says they should be.
- Capital "T" in the beginning of the second sentence of the abstract.

Also in the updated version I'd prefer to see an updated list of the papers on ChaCha: 
the ideology of the RFC is to give the alternative (e.g. as a standby cipher) to AES in the protocols, so an up-to-date relevant list of publications on the alternative algorithms would be helpful. Maybe the authors have 
thought on this and have come to a conclusion that no update is needed though.

Some editorial comments, related to the original RFC:
1) "Professor Bernstein's paper" -> "[ChaCha]".
2) Section 2.5: do we really need a c-code (together with #include...) instead of pseudocode here?
3) To add to the Russ Housley's list of unnecessary bullets and line numbers: are "@@@" needed in A.5?
4) For "+", "^" and "<<<" definitions are given and for "|" (again - already spotted by Russ) and for "&" they are not - some revision here would be helpful.

And one more minor comment: the statements in 2.7 about the PRFs may be more accurate, if instead of (or in addition to) informal words (about HMAC that are used as PRF and that Poly1305 should not) references to the formal PRF property and papers with proofs of HMAC would be given.

Nevertheless, in my opinion, the document is very close to being ready and should be adopted by CFRG (after these minor corrections).

Best regards,
Stanislav V. Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC

2017-01-18 21:30 GMT+03:00 Russ Housley <[e-mail]>:
Document: draft-nir-cfrg-rfc7539bis-00
Reviewer: Russ Housley
Review Date: 2017-01-19

Summary: Almost Ready

Major Concerns:

The Abstract says that there are additions to the Security
Considerations; however, I do not see a difference between the
Security Considerations in this document and RFC 7539.


Minor Concerns:

In Section 2.3.1, please add a sentence to define the "|" operator
in a manner similar to the definition for "+" in Section 2.1.


Nits:

Abstract: s/any new crypto/any new cryptographic mechanisms/

Section 2.1 uses "rotation" and "roll" to describe the same operation.
Please pick one term.

In Sections 2.1 and 2.3, I do not think that the line numbers aid the
reader. I think that simple indention would be better.

In Sections 2.1 and 2.1.1, I do not think that the bullets aid the
reader.  I think that simple indention would be better.

Section 2.5.1 includes: r = (le_bytes_to_num(key[0..15]).
I think you want to drop the leading parenthesis.

In Author's address, please capitalize "st."

_______________________________________________
Cfrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg