On 2/3/19 12:34 AM, Richard Laager wrote: > For the server to client direction, we would have to store the counter > state in the cookie. Given that cookies are preallocated, this would > take _two_ numbers: the current counter value to use with that cookie > and the maximum counter valued issued.
Upon further reflection, this does NOT work. It is obviously broken right away under normal conditions: > [(1, 8), (2, 8), (3, 8), (4, 8), (5, 8), (6, 8), (7, 8), (8, 8)] The first request sends a cookie with a max_count of 8, so we issue a replacement cookie just fine: >>> list(cookies(8, 1)) [(9, 9)] However, the second cookie still contains the old max_count of 8, so we issue the replacement cookie with a duplicate nonce and security fails: >>> list(cookies(8, 1)) [(9, 9)] 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. Accordingly, the nonce _has_ to be a random value. Then, if you use something (like AES-GCM) that requires non-duplicated nonces, you're banking all of your security on not having a collision in your random numbers. That sounds pretty risky when the only reason to consider AES-GCM is as a backup to AES-SIV-CMAC. Therefore, I conclude that the NTP cipher needs to be a nonce-reuse-resistant algorithm. That's currently AES-SIV-CMAC (the default and REQUIRED algorithm from the spec) and the newly-spec'ed AES-GCM-SIV. Therefore, I would propose that _only_ AES-SIV-CMAC be used for now. Pending verification by a crypto expert, AES-GCM-SIV could be considered in the future as a backup algorithm. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
