Nonce Reuse (Was: Re: C2S/S2C lifetime)

[Richard Laager]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190203/06bf21ed/attachment.bin>