C2S/S2C lifetime

[Richard Laager]

On 2/2/19 6:25 PM, Gary E. Miller via devel wrote:
> On Sat, 02 Feb 2019 16:15:49 -0800
> Hal Murray <hmurray at megapathdsl.net> wrote:
> 
>> Gary said:
>>> Nothing says that a single cookie could not be used by a farm of
>>> clients to push the cookies per second into the thousands.  
>>
>>> Then add that this is millions of know plaintext and known
>>> ciphertext pairs That is not what the key reuse calculations
>>> assume.   
>>
>> I'm missing a step.  How are you getting known plaintext/cyphertext
>> pairs?
> 
> The whole point is that the client knows the C2S and S2C.  Otherwise
> he can not key a session to the NTPD server.  That is the plaintext.
> And he has the cookie, with the algorithm use to make it.  That is
> the ciphertext.

You are describing a known-plaintext attack on K, which the draft
recommends rotating e.g. daily keeping one previous. So your window of
time here is, for example, two days. I think everyone agrees that K
should be rotated.

Hal's comments and the quote from Daniel are about whether it is
necessary to require rotation of C2S/S2C, not K. The NTS protocol does
not rotate C2S/S2C. Clients can keep their own lifetime to enforce
rotation of it (by re-running NTS-KE), but when Hal asked the working
group, Daniel said that is not necessary:

> 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.

The client isn't going to be sending one message per second either.
minpoll has a lower limit of 16 seconds. So these numbers can be scaled
up by 16.

As Hal noted, if the client wants to send out messages at a faster rate,
sure, they might weaken the security of their key, but why would they do
such a thing? In any event, they can only transmit _new_ cookies at a
rate the server will communicate with them anyway.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/71fd14d6/attachment-0001.bin>