[Gen-art] Gen-ART LC review of draft-gutmann-cms-hmac-enc-05

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 08 July 2011 20:24 UTC

Message-ID: <4E17672C.1050005@isode.com>
Date: Fri, 08 Jul 2011 21:23:08 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
To: draft-gutmann-cms-hmac-enc.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, iesg@ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-gutmann-cms-hmac-enc-05
Precedence: list

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-gutmann-cms-hmac-enc-05

Reviewer: Alexey Melnikov

Review Date: 2011-07-08

IETF LC End Date: 2011-07-20

IESG Telechat date: 2011-08-11


 

Summary: This draft is almost ready for publication as a standard track 
RFC.
 
Major issues: none
 

Minor issues:


3.  CMS Encrypt-and-Authenticate Overview

   Conventional CMS encryption uses a content encryption key (CEK) to
   encrypt a message payload.  Authenticated encryption requires two
   keys, one for encryption and a second one for authentication.  Like
   other mechanisms that use authenticated encryption, this document
   employs a pseudorandom function (PRF) to convert a single block of
   keying material into the two keys required for encryption and
   authentication.  This converts the standard CMS encryption operation:

       KEK( CEK ) || CEK( data )


It would be good to expand KEK on the first use.
Also, it would have been nice to specify all parameters here and below, 
so that it is clear where MAC-K and CEK-K are used.


   into:

       KEK( master_secret ) || MAC( CEK( data ) )

   where the MAC and encryption keys are derived from the master_secret
   via:

       MAC-K := PRF( master_secret, "authentication" );
       CEK-K := PRF( master_secret, "encryption" );


4.2.  Rationale

   Using a fixed-length key rather than making it a user-selectable
   parameter is done for the same reason as AES' quantised key lengths:
   there's no benefit to allowing, say, 137-bit keys over basic 128- and
   256-bit lengths, it adds unnecessary complexity, and if the lengths
   are user-defined then there'll always be someone who wants keys that
   go up to 12.


Excuse my ignorance, but what does "go up to 12" (and "go to 11" 
elsewhere) mean?


Nits/editorial comments:  none


 (id-nits reports one Downref, but it was called out in the IETF LC 
announcement)

[Gen-art] Gen-ART LC review of draft-gutmann-cms-… Alexey Melnikov