Re: [TLS] ChaCha and IVs

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, 2014-03-04 at 13:15 -0500, Stephen Kent wrote:

> >>  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.
> Security evaluation for a crypto alg does not include a protocol like ESP or
> (D)TLS; if focuses only on the alg implementation. Thus a TLS "guarantee"
> of uniqueness is not relevant. Anyone who has had a product evaluated will
> tell you that the goal is always to minimize the amount of code that is 
> subject
> to review. If one were to use a TLS (or ESP) sequence number for an IV, 
> all of
> the protocol code would be part of the evaluation, and that would make the
> evaluation prolonged and very costly.

I believe this was answered elsewhere in this thread.

> > * 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.
> The typical packet size in the ESP context is at least that small.
> > * It ensures that the nonce is unique even until 2^64-1 records are
> > exchanged (which is the termination limit for TLS sessions).
> this guarantee is only as good as the assurance of the TLS code than manages
> the sequence numbers, which is not likely to be secure as the alg 
> implementation.

One cannot design protocols with the assumption that they will be
violated. However, even if you are implying that implementations will
continue to exchange data even after 2^64-1 records are exchanged, then
the counter nonce approach will fail precisely at the 2^64 exchanged
record. The random nonce approach will fail much earlier.

regards,
Nikos