Re: [TLS] Pull Request: Removing the AEAD explicit IV

[Eric Rescorla <[e-mail]>]

On Thu, Mar 19, 2015 at 1:11 PM, Brian Smith <[e-mail]> wrote:

> Eric Rescorla <[e-mail]> wrote:
> > On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith <[e-mail]>
> wrote:
> >> It seems like it would be better, instead, to require that the initial
> >> nonces to be calculated from the keyblock established during key
> >> agreement,
> >
> > Is there any reason why these should be derived from the keyblock
> > as opposed to from purely public information such as the random
> > values?
>
> Intuitively, I expect the attacker to have more difficulty if they
> don't know the nonce than if they do. In general, we should not
> divulge more than the minimum amount of information in cleartext. And,
> in particular, one of the design goals is to encrypt as much of the
> handshake as possible, and the nonce selection is part of the
> handshake.
>
> I wouldn't be surprised if somebody pointed out a good reason to avoid
> deriving them out of the key block, though I don't know of one now.
>
> >> and then have them incremented as counters (with
> >> wraparound) in the same fashion as being proposed.
> >
> > Can you explain why you think they need to change? I note that TLS 1.2
> > currently does not behave in this fashion.
>
> I think you interpreted my suggested as <initial-nonce> || <record
> sequence number>.


I did. It doesn't help here that TLS uses '+' for concatenation :(




> I just mean that the per-record nonce should be
> calculated as <initial-nonce> + <record sequence number>. It seems
> better to start all the initial bits of the nonce in a randomly-chosen
> state, instead of just a prefix, if there's no conflicting
> considerations to do otherwise.
>

So to be clear we would generate a random V of length
N_MIN and then for each record the nonce would be
SN + V?


-Ekr


> Cheers,
> Brian
>