Subject: [Ntp] Antw: [EXT] Éric Vyncke's No Objection on draft-ietf-ntp-packet-timestamps-08: (with COMMENT)

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Mar 2020 11:08:31 +0100

>>> Éric Vyncke via Datatracker <[email-masked]> schrieb am 02.03.2020 um
10:55
in Nachricht
<30177_1583142964_5E5CD834_30177_3740_1_158314294320.21184.16297641213277392499@
etfa.amsl.com>:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ntp-packet-timestamps-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html 
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/ 
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. It is indeed useful to have
> common timestamp formats.
> 
> I was about to ballot a DISCUSS on the point in section 1.1 but I am 
> trusting
> the Security Area Directors for their own reviews.
> 
> Nevertheless, please find below some non-blocking COMMENTs (and I would
> appreciate a response from the authors).
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 1.1 --
> When writing "security protocols a timestamp is often used as a value that 
> is
> unlikely to repeat (nonce)", I sincerely believes that this is probably
> misleading as nonce should probably have entropy and be non-predictable. A
> timestamp does not have those properties. Again, I am trusting my SEC AD 
> peers
> on their final words.

I'm no expert either, but I think a timestamp qualifies as NONCE if you don't
know when it will be used.
In the case of NTP trying an interval of timestamps to guess the correct nonce
won't be effective I guess. If that is wrong, maybe also update the English
Wikipedia's entry for "Cryptographic_nonce".

> 
> -- Section 2.1 --
> Is BCP 14 boilerplate required for an informational document ? I have found
> only one "MUST" in the security section but again this is weird for an
> informational document.
> 
> -- Section 3 --
> Should the syntax also include the bit ordering ? I.e., little endian of
big
> endian ? Of course the default if network order but what if it is not ?
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Mon, 02 Mar 2020 02:34:19 -0800

> know when it will be used. 

I'm not a crypto wizard, but I think that is a pretty clear No if you are 
using it in a crypto context.

For a nonce, you need random bits.  The nonces used in NTS are 16 bytes.  
That's 16 bytes where all the bits are random.

There are probably use cases where "nonce" is used at a protocol level rather than in a crypto context, for example to reject duplicates.  In that case, somebody has to decide how many bits of randomness you need and/or if a time stamp fits the use case.

-- 
These are my opinions.  I hate spam.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 2 Mar 2020 13:04:36 +0000

> know when it will be used. 

If the attacker can guess the nonce value (gee, this accurately-stamped packet must have been generated within X..Y time), then it does not qualify as a nonce.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 2 Mar 2020 08:12:08 -0500

On Mon, Mar 2, 2020, 05:34 Hal Murray <[email-masked]> wrote:

> There are probably use cases where "nonce" is used at a protocol level
> rather than in a crypto context, for example to reject duplicates.  In that
> case, somebody has to decide how many bits of randomness you need and/or if
> a time stamp fits the use case.
>

"Nonce" means "number used once". That's all. It's not necessarily
something random, unpredictable, etc.; it simply has to not be used
repeatedly with the same key material. Specific protocols may impose
additional requirements on how nonces are constructed, for example NTS's
unlinkability scheme requires they be random. But this is not essential to
the definition of a nonce.