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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 01:55:43 -0800

É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.

-- 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 ?

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 3 Mar 2020 07:52:51 +0200

Hi Eric,

Many thanks for the comments.

Please see the responses below.

> timestamp does not have those properties. Again, I am trusting my SEC AD peers

I suggest the following update:
OLD:
a timestamp is often used as a value that is unlikely to repeat (nonce)
NEW:
a timestamp is often used as part of a value that is unlikely to repeat (nonce)

> only one "MUST" in the security section but again this is weird for an

Right. The draft only uses two instances of (uppercase) normative
requirement language words, one in Section 3 (which defines the
timestamp template) and the other in Section 9 (Security
Considerations). This is intentional, since these are exactly the
requirements that the reader is expected to comply to when defining a
timestamp.

> endian ? Of course the default if network order but what if it is not ?

I propose the following update:
OLD:
The number of bits (or octets) used to represent the packet timestamp
field.  If the timestamp is comprised of more than one field, the size
of each field is specified.
NEW:
The number of bits (or octets) used to represent the packet timestamp
field.  If the timestamp is comprised of more than one field, the size
of each field is specified. Network order (big endian) is assumed by
default; if this is not the case then this section explicitly
specifies the endianity.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 03 Mar 2020 08:34:50 +0100

>>> Tal Mizrahi <[email-masked]> schrieb am 03.03.2020 um 06:52 in
Nachricht
<11168_1583214812_5E5DF0DC_11168_964_1_CABUE3X=6=UkYxbj_U1ZzU=zkc53n5Zm2rqp3Gq53
aUi=[email-masked]>:

[...]
> a timestamp is often used as part of a value that is unlikely to repeat 

Maybe s/often/also/ ?

And wouldn't it be "is used often" instead of "is often used" (that work ordering is OK in Germsan, but I think not in English). And when we're at it: Maybe s/is used/(maybe|might be|could) used/ ?
[...]

Regards,
Ulrich

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 3 Mar 2020 07:35:51 +0000

Tal,

Thank you for your answers. They are all perfect for me.

I will let the security AD verify the one about the nonce though.

Regards

-éric

-----Original Message-----
From: Tal Mizrahi <[email-masked]>
Date: Tuesday, 3 March 2020 at 06:53
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Karen O'Donoghue <[email-masked]>, Suresh Krishnan <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ntp-packet-timestamps-08: (with COMMENT)

    Hi Eric,

---

From: Hal Murray <[email-masked]>
Date: Tue, 03 Mar 2020 06:05:17 -0800

[email-masked] said:
> NEW: a timestamp is often used as part of a value that is unlikely to repeat
> (nonce) 

Is there a good reference for using time as a nonce?  I'd be happier if there 
was a hint that it's easy to get times to repeat if you don't have a TOY clock.

> NEW: The number of bits (or octets) used to represent the packet timestamp
> field.  If the timestamp is comprised of more than one field, the size of
> each field is specified. Network order (big endian) is assumed by default; if
> this is not the case then this section explicitly specifies the endianity. 

Are there any RFCs that use other than big-endian?  Introducing the 
opportunity for otherwise seems like unnecessary complexity as well as an 
invitation for interoperability troubles.

-- 
These are my opinions.  I hate spam.

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 4 Mar 2020 21:06:11 +0000

Hi!

> From: iesg <[email-masked]> On Behalf Of Hal Murray
> Sent: Tuesday, March 03, 2020 9:05 AM
> To: Tal Mizrahi <[email-masked]>
> Cc: [email-masked]; [email-masked]; Karen O'Donoghue
> <[email-masked]>; The IESG <[email-masked]>; [email-masked]; Éric
> Vyncke <[email-masked]>; [email-masked];
> Suresh Krishnan <[email-masked]>
> Subject: Re: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-packet-
> timestamps-08: (with COMMENT)
> 
> 

(SEC ADs were invoked at the start of the thread, but let me jump in mid-stream ...)

Using a clock to get non-repeating value for nonce is sometimes all you can get, so given the context here, it works for me.  It might not be appropriate for all solutions.

RFC4949 has a definition of nonce.

Roman