On 2/3/19 9:50 AM, Richard Laager wrote: > On 2/3/19 12:34 AM, Richard Laager wrote: > So, given the current design of the NTS cookie replacement algorithm, > it's not going to be possible to _statelessly_ (which is a hard > requirement) maintain a counter-based nonce. I gave this some more thought (even tweaking the algorithm again to something that otherwise worked but was useless in a practical implementation).
But I eventually realized there's a far simpler way to think about this: clients are allowed to replay cookies. And even if they weren't a malicious one could. Therefore, regardless of what state the server stores in a cookie, it would re-use a nonce if the cookie is replayed. So a counter-based nonce is completely out for server-to-client NTP communications, due to the server statelessness requirement. I updated nts.adoc accordingly in one of the commits (currently the last one) on this merge request: https://gitlab.com/NTPsec/ntpsec/merge_requests/939 On a related note, from what I can see, the nonce space for AES-GCM is 12 octets, or 2^(12*8) = 2^96. Daniel said the max number of requests for AES-GCM was 2^32. I wonder if that was a safety margin against accidental collisions assuming we were using randomly-generated nonces with AES-GCM. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
