Re: [Cfrg] Fwd: Rev RFC 7539?

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 19 January 2017 13:42 UTC

Return-Path: <prvs=21922116c2=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF3B129467 for <cfrg@ietfa.amsl.com>; Thu, 19 Jan 2017 05:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.397
X-Spam-Level:
X-Spam-Status: No, score=-7.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61WJR9Gr7NSH for <cfrg@ietfa.amsl.com>; Thu, 19 Jan 2017 05:42:40 -0800 (PST)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 367091295BB for <cfrg@irtf.org>; Thu, 19 Jan 2017 05:42:39 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v0JDagYc044845; Thu, 19 Jan 2017 08:36:42 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, IRTF CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Fwd: Rev RFC 7539?
Thread-Index: AdJyWeW9pgkpUqc0Mk+z/78et8sGiA==
Date: Thu, 19 Jan 2017 13:42:38 +0000
Message-ID: <20170119134247.18296897.78355.111694@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============0333085900=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-19_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701190179
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/p8SB9k63es8dLxUSzGwU5s6gssI>
Subject: Re: [Cfrg] Fwd: Rev RFC 7539?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 13:42:42 -0000

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 <housley@vigilsec.com>:
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
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg