[Gen-art] Gen-ART review of draft-ietf-kitten-aes-cts-hmac-sha2-10
"Vijay K. Gurbani" <vijay.gurbani@nokia-bell-labs.com> Fri, 29 July 2016 18:54 UTC
Return-Path: <vijay.gurbani@nokia-bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3E12B043; Fri, 29 Jul 2016 11:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 zHH9OPTgfCNX; Fri, 29 Jul 2016 11:54:55 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E13128E19; Fri, 29 Jul 2016 11:54:55 -0700 (PDT)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 6C600B3672A40; Fri, 29 Jul 2016 18:54:51 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6TIssqD017045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2016 18:54:54 GMT
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6TIsrHA015728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jul 2016 18:54:53 GMT
Received: from [135.185.238.141] (shoonya.ih.lucent.com [135.185.238.141]) by umail.lucent.com (8.13.8/TPES) with ESMTP id u6TIsrYM019845; Fri, 29 Jul 2016 13:54:53 -0500 (CDT)
From: "Vijay K. Gurbani" <vijay.gurbani@nokia-bell-labs.com>
To: draft-ietf-kitten-aes-cts-hmac-sha2@ietf.org
Message-ID: <d418a174-5467-76c2-72f9-e9dcb41fdb57@nokia-bell-labs.com>
Date: Fri, 29 Jul 2016 13:54:53 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/n64gGoEg8aVZRtXUs7pLUOxjWiY>
Cc: draft-ietf-kitten-aes-cts-hmac-sha2.chairs@ietf.org, General Area Review Team <gen-art@ietf.org>, draft-ietf-kitten-aes-cts-hmac-sha2.shepherd@ietf.org, iesg@ietf.org
Subject: [Gen-art] Gen-ART review of draft-ietf-kitten-aes-cts-hmac-sha2-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2016 18:54:58 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-kitten-aes-cts-hmac-sha2-10 Reviewer: Vijay K. Gurbani Review Date: Jul-29-2016 IETF LC End Date: Jul-20-2016 IESG Telechat date: Unknown This document is ready as an Informational. Major: 0 Minor: 2 Nits: 1 Minor: - S3, top of page 4, while defining "context": What is the format of this optional string: is it comma separated? Or does it not matter because the byte-string in context is supposed to be an opaque label? I ask because the byte-string can contain multiple values (identities of parties, nonce, etc.); consequently, how does a receiver know where one value ended and another one began. I realize that when "context" is used for key derivation in the KDF, individual elements of the "context" does not matter; but since the text makes the point that "context" may include "identities of parties who are deriving and/or using the derived key material...", it seems appropriate that the recipient know what separates the ID from the nonce. - S3, middle of page 4: "When the encryption type is aes128-cts-hmac-sha256-128, k must be no greater than 256." 256 what? Bits (I believe). Similarly for 384. Better to be complete. Nits: - S1, second paragraph: "...but do not use the simplified profile." Any insight into why simplified profile is not used may be helpful to the reader for the sake of completeness. (Of course, if the reasons that the simplified profile is not being used are blatantly obvious to practicioners in this field, then don't worry about this comment. But if not, it may help.) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@nokia.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
- Re: [Gen-art] Gen-ART review of draft-ietf-kitten… Jari Arkko
- [Gen-art] Gen-ART review of draft-ietf-kitten-aes… Vijay K. Gurbani