[Cfrg] New Version Notification for draft-mcgrew-iv-gen-01.txt

David McGrew <mcgrew@cisco.com> Mon, 31 October 2011 15:28 UTC

Return-Path: <mcgrew@cisco.com>
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 09DC011E80B0 for <cfrg@ietfa.amsl.com>; Mon, 31 Oct 2011 08:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level:
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1MsIghwCL2v for <cfrg@ietfa.amsl.com>; Mon, 31 Oct 2011 08:28:19 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 067C011E80A5 for <cfrg@irtf.org>; Mon, 31 Oct 2011 08:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=5852; q=dns/txt; s=iport; t=1320074899; x=1321284499; h=cc:message-id:from:to:content-transfer-encoding: mime-version:subject:date:references; bh=GaM597nxpTvQgW0Bxm2RdSOWX20BrjJVI9wGmeaVclI=; b=lF+D4JVl6b3fQAEcWNjnAbg0QH4udycZagEF22Wluu2MK/F+RlfKL1kp HGdr973b4MHeeworZjw2uS5MMMnTaLh5cgHqvfMCZT7gcv4ttURU12zaF 7geQo7yipWealaxl+M2LUol0d6fk3BKGpZ7bxZTs7ydmZChXx5XZSIkCr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAJC9rk6rRDoI/2dsb2JhbABDpyWCEIEFgXIBAQEBAgESASUCPQIQUVc7h2CVUgGeGoghYQSIBowIkX8
X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208";a="11420948"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 31 Oct 2011 15:28:18 +0000
Received: from stealth-10-32-254-213.cisco.com (stealth-10-32-254-213.cisco.com [10.32.254.213]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9VFSHkX012465; Mon, 31 Oct 2011 15:28:18 GMT
Message-Id: <D178AE20-C343-46E9-8A80-591749254C8C@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: cfrg@irtf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 31 Oct 2011 08:28:17 -0700
References: <20111031152030.4873.11841.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.936)
Subject: [Cfrg] New Version Notification for draft-mcgrew-iv-gen-01.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 15:28:20 -0000

Hi,

an updated version of the draft just went in.  It has text to address  
some comments from reviewers; there is a diff below with the new text.

regards,

David

Begin forwarded message:

>
> A new version of I-D, draft-mcgrew-iv-gen-01.txt has been  
> successfully submitted by David McGrew and posted to the IETF  
> repository.
>
> Filename:	 draft-mcgrew-iv-gen
> Revision:	 01
> Title:		 Generation of Deterministic Initialization Vectors (IVs)  
> and Nonces
> Creation date:	 2011-10-31
> WG ID:		 Individual Submission
> Number of pages: 25
>
> Abstract:
>   Many cryptographic algorithms use deterministic IVs, including CTR,
>   GCM, CCM, GMAC.  This type of IV is also called a (deterministic)
>   nonce.  Deterministic IVs must be distinct, for each fixed key, to
>   guarantee the security of the algorithm.  This note describes best
>   practices for the generation of such IVs, and summarizes how they  
> are
>   generated and used in different protocols.  Some problem areas are
>   highlighted, and test considerations are outlined.  This note will  
> be
>   useful to implementers of algorithms using deterministic IVs, and to
>   protocol or system designers using them.
>

< Internet-Draft         Deterministic IV Generation             July  
2011
---
 > Internet-Draft         Deterministic IV Generation          October  
2011
343,345c343,345
<    [RFC4106], TLS [RFC5288], SSH [RFC5647], and SRTP .  The way that
<    these protocols define their IVs is outlined in this section and is
<    summarized in Table 1.
---
 >    [RFC4106], TLS [RFC5288], SSH [RFC5647], and SRTP [RFC3711].   
The way
 >    that these protocols define their IVs is outlined in this  
section and
 >    is summarized in Table 1.

 >    The partially implicit format can save on bandwidth or data  
storage
 >    requirements, because it avoids sending or storing the implicit  
part
 >    of the IV.  However, it limits the number of IVs that can be
 >    generated, because the implicit part is fixed, and it adds  
complexity
 >    to the system, by making the system coordinate the implicit part
 >    through out-of-band means.  Thus, new protocol and system designs
 >    SHOULD NOT use the partially implicit format unless a review of  
all
 >    of the issues shows that the bandwidth or storage savings are  
worth
 >    the complexity.  (An alternative strategy for bandwidth savings is
 >    discussed in Section 7.4.)
 >


<    Fixed field and the Counter field are concatenated, then they are
<    bitwise exclusive-ored with the Salt field, and the resulting value
<    is the IV.  The Counter is incremented, treating it as an unsigned
<    integer with the most significant byte on the left, and the stored
<    Counter field is set to the incremented value.  Then the IV is
<    returned.
---
 >    stored Counter value MUST be checked to determine if an IV can be
 >    generated; an IV can only be generated if the value of Counter + 1
 >    does not exceed the maximum allowable value of the Counter  
field.  If
 >    an IV cannot be generated, then the operation returns an  
indication
 >    that there are no more IVs that are available.  Otherwise, the  
Fixed
 >    field and the Counter field are concatenated, then they are  
bitwise
 >    exclusive-ored with the Salt field, and the resulting value is the
 >    IV.  The Counter is incremented, treating it as an unsigned  
integer
 >    with the most significant byte on the left, and the stored Counter
 >    field is set to the incremented value.  Then the IV is returned.


 > 7.4.  Bandwidth Use
 >
 >    An implicit or partially implicit IV uses less bandwidth than a  
full-
 >    sized IV.  But as noted above, the (partially) implicit IV format
 >    reduces the number of IVs that can be generated and adds  
complexity
 >    to the system.
 >
 >    An alternative approach to bandwidth savings in a protocol  
design is
 >    to use a predictable IV format, such as that of Section 4.1, and  
then
 >    apply header compression to the IV.  Header compression is often  
used
 >    on bandwidth-constrained links, and it can be applied to encrypted
 >    packets [RFC3095].  The format of Section 4.1 can easily be  
handled
 >    by header compression.  This approach has several benefits: it  
makes
 >    IV generation simpler, it allows bandwidth savings for  
environments
 >    in which it matters while putting the complexity burden onto the
 >    systems that opt to realize those savings, and it increases the
 >    number of IVs that can be used.  Specifications that use this  
design
 >    alternative SHOULD require the use of the IV format in Section  
4.1.
 >


 >
 >    Almost all cryptographic systems can implement counter-based
 >    deterministic IVs.  In many cases, it is straightforward to  
generate
 >    deterministic IVs associated with a short-term key in use by a  
single
 >    encrypter, as in a typical point-to-point protocol.  Complications
 >    can arise, however, when there are multiple encrypters, or when  
a key
 >    is used for an extended period of time.  Cryptographic systems  
that
 >    cannot ensure IV distinctness should not use deterministic IVs,  
and
 >    should instead use a misuse-resistant mode of operation such as  
the
 >    Synthetic Initialization Vector (SIV) Authenticated Encryption  
mode
 >    of operation [RFC5295], or a randomized algorithm such as the CBC
 >    mode of operation (though an additional authentication mechanism  
must
 >    be used with that option).  If authentication but not encryption  
is
 >    required, then it is possible to use an algorithm that does not
 >    require an IV, such as HMAC [RFC2104].
 >