First round of my stupid questions about NTS

[Hal Murray]

esr at thyrsus.com said:
[Context is recipe for switching to a new cookie format.]
> That should go in nts.adoc.  When we *choose* one of those alternatives,
> we'll edit. 

Seems like clutter to me.  I worked out that level of detail about as fast as 
I could type it in.

> What I'd prefer is a plan where there is one oracle that both generates and
> analyzes cookies, with other agents treating them as opaque blobs to be
> passed around and at worst compared for binary equality if they're operated
> on at all.  Dunno if I can *get* that, but it's what I'd consider ideal. 

That's a different discussion.  It's also easy to get.  The oracle is NTP 
server.  Here is the recipe:

Cookies are generated by NTP-server.  To do that, it needs S2C and C2S and an 
AEAD algorithm.

There are 2 cases.  For cookies going back to a NTP client, S2C and C2S came 
from the cookie in the request packet (mode 3) that the NTP client sent.  Same 
AEAD.

The other case is the initial cookies going via NTS-KE.  To get those, we need 
a connection from NTS-KE server to NTP server.  The NTS-KE server sends S2C 
and C2S.  It gets back 8 cookies.  The AEAD algorithms also go in here.

I have already typed most of that in.  I'll push soon.  I didn't remove the 
Echo stuff.

--------

That does bring up an interesting point.  We now have a mechanism to cleanly 
shut down a NTP server.  Just turn off the NTS-KE server then have the NTP 
server start responding with crypto NACKs.

With the indirection through NTS-KE, it's harder for admins to wire an IP 
address into ntp.conf.

Of course, they can hammer on the NTS-KE server.


-- 
These are my opinions.  I hate spam.