My plans, suggestions and whatever

[Hal Murray]

Step one is to get nts_probe() far enough along to check certificates.  This 
is mostly copying over the details from my hack client and making it build on 
older versions of OpenSSL.

We can test that code in ntpd by testing the NTS flag just before the current 
code tests the DNS flag and calling out to the partial version of nts_probe() 
which gets a test run then turns off the NTS flag so it only happens once.  I 
can test that much talking to my hack server.

Step two is to get nts_probe() to send sensible requests.  That needs 
nts_append_record().
(I can easily fake that.  The request is only 16 hex bytes.)

Step 3 is to shift to the server.  I haven't thought much about this.  It will 
need nts_next_record() and nts_new_cookie().

Then I go back to nts_probe and process the answer.
Then we put a cookie in the request packet.
Then we teach the server to process cookies.
Then we get the client to process responses with cookies.

---------

I think the buffer struct for nts_append_record and nts_next_record only needs 
the current pointer and length remaining.  Earlier, I probably said it should 
have the base pointer and total length.  They aren't needed by the workers and 
the guy who would build that struct already know the base/length.



nts_new_cookie will need to be thread safe.

nts_lib has nts_cookie_prep that looks like it's trying to be nts_new_cookie.  
But the comment says Allocate.  I don't want any allocate/free.  I'll pass in 
a pointer/maxlength for where to put it and whatever else is needed.  We 
should probably use the same buffer-block used by nts_append_record and 
nts_next_record()

cookie_bits has all sorts of junk that I don't understand.  Something like 
that as a parameter to new_cookie and unpack_cookie probably makes sense but I 
think it should contain only what is absolutely necessary.  I don't have a 
list handy.  Here is my quick guess:
  AEAD algo
  C2S, S2C, length

I'm assuming that unpack_cookie will fill in the pointers for C2S and S2C 
pointing into the decrypted cookie.  No data copying.

I'm trying to look ahead to the NTP-server case.  This may be only half-baked. 
 The basic question is where/when to copy data.

I'm assuming that encrypt/decrypt routines can update the data in place.

There are 2 levels of encryption.  Parts of cookies get encrypted/decrypted 
with K.  That's all hidden inside new_cookie and unpack_cookie.  New 
(encrypted) cookies are also encrypted with S2C in NTP- response packets.

I'm assuming that new_cookie will encrypt in place.

For unpack_cookie, we need to do a copy anyway, so we might as well let the 
decryption do it.

There are 3 places where we will create/unpack cookies.  The NTS-KE-server 
needs new cookies.  It will have a buffer to build them in.  Easy.

The NTP-server needs to unpack one cookie, and get a new one (maybe several) 
to send back.  We can't decrypt in place since that would trash the packet 
that we haven't authenticated yet.  Even if we could authenticate, we need to 
make a safe copy so we can write the extensions for the response in the packet 
buffer we will be returning.  So the receive logic that scans the extensions 
has to copy over the cookie - or defer the copy until AEAD decryption.

---------

We need to find the length of C2S and S2C.  (and document where we found it)



-- 
These are my opinions.  I hate spam.