[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