ntp.conf changes for NTS

[Gary E. Miller]

Yo Achim!

On Thu, 31 Jan 2019 22:19:14 +0100
Achim Gratz via devel <devel at ntpsec.org> wrote:

> Gary E. Miller via devel writes:
> > The C2S and S2C already get reused millions of times, what's a few
> > more million?  
> 
> Both keys should only ever be used by a single client/server pair.

Yeah, but no way to enforce that.  A black-, white-, or gray-hat could
easily reuse the same keys on thousands of servers at the same time.

You easily get up to millions of known plaintext/known ciphertext pairs,
the nonces become overwhelmed and the master key recovered.

> These are symmetric keys, so whoever knows them can encrypt and
> decrypt all messages that use them.

Yup.

> So sharing these keys among
> different servers would imply trust between them and hopefully we can
> agree that different pool servers are in no such relationship.

By definition there is no trust in the pool.

> > But, as you said, the TLS "has" to be renegotiated, so that state
> > is lost for the next request.  
> 
> No, re-keyed -- you specifically want to avoid the TLS renegotiation
> or even worse, reconnection.  The session itself stays open.

OK, re-keyed, but I see nothing in the Proposed RFC to support this mode
of operation.  Sure, TLS alone supports re-keying, but the NTPD client
has no way to request a 2nd, different, NTPD server and cookie.

> You
> could conceivably just open another connection inside the same
> session as far as TLS is concerned.  I don't know which of the two
> options is more efficient.

Neither, until the Proposed RFC supports it.

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/20190131/2ef2a250/attachment.bin>