e...@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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
