Rekeying C2S and S2C is not necessary

[Hal Murray]

Gary said:
> Really?  So unlimmited numbers of packets with identical C2S, S2S and master
> key, differing only int ehnonce is not a problem?

> Pretty much every crypto algorithm I know of has a recommended maximum number
> of uses.  Allowing these two to be used unlimited times is violating absic
> crypto principles goint back to well before how Enigma, and other ciphers,
> were broken. 

Correct.

But they picked an algorithm with a large recommended max.  If you do the 
math, it's conservatively longer than a client will stay up.

>From mail last night:
----------
The per client-server pair of keys, C2S and S2C don't roll over as long as the 
connection works reasonably well.  I asked about key lifetime on the NTP list 
and Daniel said we don't have to worry about it.
  https://mailarchive.ietf.org/arch/msg/ntp/lV74s2I97P8ncJdjsIKvlcAgEG0

> The recommendation for AES-SIV is to encrypt no more than 2**48
> messages under the same key. At one message per second that's almost 9
> million years. If you (unwisely) use AES-GCM instead, where the
> recommended limit is 2**32 messages, that's still 136 years.
----------

9 million years isn't the heat death of the universe, but it's long enough 
that we don't need to worry about it.

Eric said:
>>> What you almost need is a cookie extension to trigger a rekeying
>>> periodically.
>> Yes.  Sad the Proposed RFC is silent on the subject.  Seems a gaping
>> hole to me.
> Would you please add this to the nts.adoc list of issues we need to bring up
> at the WG meeting. 

No!


-- 
These are my opinions.  I hate spam.