Re: [TLS] ChaCha and IVs

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, 2014-03-04 at 11:53 -0500, Stephen Kent wrote:

> I reviewed several reasons for this, based on discussions that took place in
> the IPsec WG several years ago, when we considered the same topic for 
> AES counter
> mode use with ESP. We decided to require each packet to carry an IV 
> independent of
> the ESP sequence number (or extended sequence number). Slide 5 of my 
> presentation
> enumerates reasons for not re-using a packet/record sequence number for 
> an IV.

Hello,
 I believe there advantages in using the record sequence number for an
IV _in TLS_, but before mentioning them, I'll make some comments on your
points.
 
> From a security assurance perspective, an IV based on a 
> protocol-supplied value expands the scope of what has to 
> be analyzed (to ensure uniqueness) 

In TLS the record sequence numbers are unique by definition, thus any
analysis is simplified.

> An algorithm implementation submitted for FIPS evaluation 
> must be independently evaluable 

>From the wording I don't understand how this is relevant to your point
for nonces. Could you elaborate?

> If DTLS and ESP adopt different IV approaches for the 
> same algorithm/mode, chip vendors have problems 

By problems I suppose that you mean that they have to implement a module
that works with both. 

> In some cases, a non-counter IV approach can be faster 
> than a counter (in hardware) 

I don't think that this is a good argument against implicit nonces. In
software the counter IV approach is always faster.

> Allowing each sender to choose its own IV generation 
> approach is more flexible 

Indeed, but flexibility in security protocols isn't an advantage, and I
don't see what is the actual gain from such flexibility.


So now for the arguments for using the record sequence number as (part
of) the nonce in TLS:
* It reduces the exchanged data (by 12 or 8 bytes - depending on the
explicit nonce size). This is particularly important in DTLS where the
typical record size is less than 1400 bytes.

* It ensures that the nonce is unique even until 2^64-1 records are
exchanged (which is the termination limit for TLS sessions).

regards,
Nikos