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

[David McGrew <[e-mail]>]

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].
 >