Re: [TLS] ChaCha and IVs

[Stephen Kent <[e-mail]>]

Nikos,
>> 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.
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.
>
>> 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?
As noted above, if one submits an implementation of AES (or, maybe 
later, ChaCha)
for evaluation by NIST or a NIST-certified lab, the alg implementation 
is evaluated
by itself, independent of any protocol. if you look at the FIPS 140-x 
list of evaluated
products you'll see that they are evaluated wrt crypto security, not wrt 
a protocol
that uses the crypto. This is true even if a product is a crypto 
accelerator for IPsec
or TLS.
>
>> 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.
yes.
>
>> 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.
yes, but software is not the only game in town. If thousands of sessions 
terminate
at a collection of servers it has been common practice to use hardware 
to offload the
processing from the servers. This also affords better protection to the 
traffic keys.
>> 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.
In this case the flexibility is desirable because it allows different
implementations to decide how to manage the IVs, as senders, without
the need to coordinate with receivers.
> 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.
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.


Steve