C2S/S2C lifetime

[Gary E. Miller]

Yo Richard!

On Sat, 2 Feb 2019 18:42:52 -0600
Richard Laager via devel <devel at ntpsec.org> wrote:

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

Reread the draft.   Section 6:

    The need to keep keys synchronized between NTS-KE and NTP servers
    as well as across load-balanced clusters can make automatic key
    rotation challenging.  However, the task can be accomplished without
    the need for central key-management infrastructure by using a
    ratchet,

The key is NOT rotated and NOT replaced.  It is 'ratcheted'.

So any master key K that I can eliminate today, I can use the same
ratchet, and eliminate tommorrow.

So, the known plain text/known cipher text pairs accumulate.

> Hal's comments and the quote from Daniel are about whether it is
> necessary to require rotation of C2S/S2C, not K.

Yes.

> The NTS protocol does
> not rotate C2S/S2C.

Yes, that is bad.

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

Yes.  Using flawed assumptions.  Such as only one client using the
same key.

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

But what if a thousand AWS instances hit the NIST servers with the same
cookie for days, weeks, months.  Each at one second intervals.  10e11
comes quickly.  Add in a flaw that NSA planted in the crypto.  Game
over.

And history has taught us, over and over again, that crypto is never
as string as we thought it was, and black hats are more clever than
expected.

Set a limit, respect it, done.  That is what pretty much every other
crypto program I know of does.

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

To recover K of course.  Then: Game Over, NTPD server compromised.

> In any event, they can only transmit
> _new_ cookies at a rate the server will communicate with them anyway.

Which, as we know, is quite high.

Since their IS a recommended limit, it should be respected.  And
very conservatively.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/e1c81472/attachment.bin>