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
- [Cfrg] Rev RFC 7539? Yoav Nir
- Re: [Cfrg] Rev RFC 7539? Eric Rescorla
- Re: [Cfrg] Rev RFC 7539? Alexey Melnikov
- Re: [Cfrg] Rev RFC 7539? John Mattsson
- Re: [Cfrg] Rev RFC 7539? Sean Turner
- Re: [Cfrg] Rev RFC 7539? Yoav Nir
- [Cfrg] Fwd: Rev RFC 7539? Yoav Nir
- Re: [Cfrg] Fwd: Rev RFC 7539? Paterson, Kenny
- Re: [Cfrg] Fwd: Rev RFC 7539? John Mattsson
- Re: [Cfrg] Fwd: Rev RFC 7539? Russ Housley
- Re: [Cfrg] Fwd: Rev RFC 7539? Stanislav V. Smyshlyaev
- Re: [Cfrg] Fwd: Rev RFC 7539? Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Rev RFC 7539? Paterson, Kenny