Yo Hal! On Thu, 10 Jan 2019 19:49:33 -0800 Hal Murray via devel <devel@ntpsec.org> wrote:
> Gary said:
> > The client does not update his cookie(s), he just asks the NTS-KE
> > for new ones when the NTPD NAKs the one he has been using.
>
> Not quite. An important idea is that cookies are only used once.
> That prevents bad guys from tracking you.
>
> In the normal case, the client sends a cookie and gets back an
> encrypted cookie.
Ah, there is is Section 1.2 page 6:
"The NTP server uses the cookie to recover this key material and
send back an authenticated response. The response includes a fresh,
encrypted cookie which the client then sends back in the clear in a
subsequent request. "
> The client starts with 8 cookies.
Maybe. Section 4.1.8, page 11:
"Servers MUST send at least one record of this type, and SHOULD send
eight of them,"
> If a packet gets lost, the next
> request includes a single cookie-please slot. The server returns an
> extra cookie so the client is back to 8. The cookie-please slot has
> the same length as a cookie slot so you can't use cookie-please as an
> amplifier. If more then 1 packet has been lost, more then one
> cookie-please slots can be sent.
I can't find this near the keyword 'please' in the Proposed RFC.
Where?
> If 8 packets are lost, the client has to go through NTS-KE again.
Replace 8 with n. Lost or NAK'ed.
We are gonna need a timeline for all these packet exchanges.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@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
pgpSiCIrn6wdW.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
