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

[Richard Laager]

Hal, does Daniel have any comment on the suitability of the new
AES-GCM-SIV for cookies and/or NTP packets?

----

Upon further research, even setting aside the message count topic,
AES-GCM is probably inappropriate for the cookie encryption.

The AES-GCM RFC (RFC 5116) says (page 13):

   The inadvertent reuse of the same nonce by two invocations of the GCM
   encryption operation, with the same key, but with distinct plaintext
   values, undermines the confidentiality of the plaintexts protected in
   those two invocations, and undermines all of the authenticity and
   integrity protection provided by that key.  For this reason, GCM
   should only be used whenever nonce uniqueness can be provided with
   assurance.

Here is an example showing a catastrophic failure in AES-GCM due to
nonce duplication:
https://cryptologie.net/article/361/breaking-https-aes-gcm-or-a-part-of-it/

The NTS draft suggests generating the nonce for cookie encryptions
randomly, so nonce uniqueness cannot be assured. Thus it says "The
chosen algorithm should be one such as AEAD_AES_SIV_CMAC_256 [RFC5297]
which resists accidental nonce reuse."

Otherwise, one would need to ensure that the nonce is _never_ reused per
key. Obviously, implementing a counter for the nonce is easy, but if the
key K is persisted, the nonce needs to be reliably persisted with it
too. That gets trickier.

Have we decided if key K is persisted across daemon (ntpd, ntsked, or
both) restarts?

I've looked through the list of AEAD algorithms. Besides AES-SIV-CMAC,
they all require non-repeated nonces, except for the very new and
not-quite-published-as-RFC AES-GCM-SIV which was created explicitly for
this purpose:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/

So AES-GCM-SIV is probably a reasonable backup to AES-SIV-CMAC, but it'd
be nice to get that answer from someone more knowledgeable.

For NTP traffic, _if_ we wanted to allow for an algorithm that requires
unique nonce values (e.g. because we need a backup algorithm)...

It should be trivial to keep the nonce unique in the client to server
direction, as the client can just keep a local nonce counter in memory.
In other words, this should be a matter of using the SSL library in the
totally normal way.

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.

Here is an example in Python, returning only the two nonce counter
values for the cookie:

 >>> def cookies(max_from_old_cookie, cookies_to_issue):
 ...     new_max = max_from_old_cookie + cookies_to_issue
 ...     x = max_from_old_cookie
 ...     for y in range(cookies_to_issue):
 ...         x = x + 1
 ...         yield (x, new_max)
 ...

 # Issue the initial 8 cookies.
 >>> list(cookies(0, 8))
 [(1, 8), (2, 8), (3, 8), (4, 8), (5, 8), (6, 8), (7, 8), (8, 8)]

 # Fill a request for 2 cookies.
 >>> list(cookies(8, 2))
 [(9, 10), (10, 10)]

 # Fill a request for 3 cookies.
 >>> list(cookies(10, 3))
 [(11, 13), (12, 13), (13, 13)]

 # Fill a request for 1 cookie.
 >>> list(cookies(13, 1))
 [(14, 14)]

-- 
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/84e2ab5e/attachment-0001.bin>