Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex

Danny Mayer <> Mon, 27 September 2021 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 882AB3A0A80 for <>; Mon, 27 Sep 2021 09:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8yb_oxLj6jQ2 for <>; Mon, 27 Sep 2021 09:31:12 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:205::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E27D3A0A7D for <>; Mon, 27 Sep 2021 09:31:05 -0700 (PDT)
Received: from newusers-MBP.fios-router.home ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4HJ7Rp0VlYzMNQf; Mon, 27 Sep 2021 16:31:01 +0000 (UTC)
From: Danny Mayer <>
To: Watson Ladd <>
Cc: Marcus Dansarie <>, NTP WG <>, JP Sugarbroad <>
References: <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Mon, 27 Sep 2021 12:31:00 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Sep 2021 16:31:17 -0000

I have been reviewing the draft again and it's not ready for 
publication. Here are a number of additional issues.

1. Section 6: "Servers SHOULD support the UDP transport mode, while TCP 
transport is OPTIONAL."

Unless you specify some other transport one of these needs to be 
mandatory. "SHOULD" is probably a "MUST". There is no explanation about 
why TCP might be used instead of UDP, so that needs clarification. If 
there is a good reason to be sending multiple requests and responses 
over TCP, please explain why this is preferable.

2. The message format (Figure 1) seems bizarre. Number of pairs

The number of pairs shouldn't need 32 bits, I suspect that 16-bits is 
more than enough. You can use the rest of the 16 bits for something 
else, like version information.

3. The message format (Figure 1). You seem to have tag identifiers after 
offsets and then values. Why not have the tag followed by a length of 
the value followed by the label? Why are you going to all the trouble of 
using offsets? Even if you are going to use offsets why isn't the tag 
identifier before the offset or even a tag identifier with the offset? 
The offsets don't need to be 32-bits in size, 16-bits is more than 
enough unless you are intending to send megabytes of packets. Note that 
is seems to be assumed that the offsets are in exactly the same order as 
the tag identifier specified separately. That's a bad assumption to 
make. It's not clear why the offsets have to be in strict ascending 
order, it shouldn't matter as long as you can correlate it to the tag 

4. TAG values

Here's another problem. Consider this from section 6.1.1: "the VER tag 
contains a list of versions". Actually the tag appears to be just a tag. 
If I interpreted the format from Figure 1 correctly, the TAG identifier 
is separate from the values and in this case the list of versions. None 
of the TAGs specified in section 6 specify the format of these values 
and what the list in the case of VER would look like. The length of 
these values are not specified anywhere except in the offset section 
which has to then interpret how long the value is which may or may not 
be a multiple of 4 bytes.

5. VER values

That is the meaning of the version? What does the version depend on? Is 
this the version of the protocol? Of the message? Of something else?

6. Secton 6.2.5 SREP

This is totally unclear. If references other tags: ROOT, MIDP, RADI, 
DUT1, DTAI, LEAP, but they seem to be part of the SREP values rather 
then part of the overall message. Are they a separate set of tags or do 
they only appear under SREP and if only under SREP then how is SREP 

7. INDX tag

It's unclear what the need for this tag is. Section 6.2.7 says that it 
identifies the postion of the NONC but since the NONC is already in the 
message this seems to be a duplicate. The reference to the Merkle tree 
doesn't clarify this at all. Confusingly then Section 6.3.1 goes on to 
say: "The bits of INDX are ordered from least to most significant in 
this algorithm" which seems to be unrelated to the NONC.


The contents seem to include other tags. It's not clear why these, like 
the ones mentioned in SREP are not separately specified.

9. Hashing algorithm in Section 6.3

It's not clear why the algorithm can only be SHA-512. This really should 
be separately referenced so that if SHA-512 is considered too week in 
can be replaced by a different hashing algorithm like say HMAC-SHA-512, 
without having to update the proposed RFC.

10. Grease (Section 8)

This seems to be garbled: "Servers MUST NOT send back responses with 
incorrect times and valid signatures.  Either signature MAY be invalid 
for this application." What does that even mean?

10. Examples of each and every tag and value would be helpful. It's hard 
to understand what each tag is providing and how the values are 
formatted and interpreted.

This is enough for now.