Re: [Ntp] Roughtime draft

[Marcus Dansarie <[e-mail]>]

Hi!

I've heard about Roughtime before and have had it described to me, but
this is the first time I have actually read a specification. After
reading through the draft, I made a quick client implementation in
Python which is available on Github: https://github.com/dansarie/pyroughtime

Here's a couple of comments and suggestions based on my first impressions:

First of all, I like how simple and straightforward the protocol is. It
should be possible to implement even on small platforms. I also note
that it is possible to create a very small client implementation
entirely without any cryptographic functions. (Though it's not a good
idea to do so other than in very special circumstances.) The
amortization of the signatures over a (possibly) large number of
requests is a nice idea.

In Section 1, the draft says that "newer protocols like [NTS] fail to
ensure that the servers behave correctly." This is technically true,
because it is not a design goal of NTS. When using NTS, server
misbehavior is detected by the same means as in standard NTP. All but
the simplest NTP implementations have the capability to detect rogue
time servers and Chronos represents the state-of-the-art in doing so.
That said, I don't dispute the motivation or need for Roughtime.

A couple of nits in Section 3:
* "The response inculdes" should be "The response includes"
* "used to indicate the servers certainty" should be "used to indicate
the server's certainty"
* "response so that its needed to" should be "response so that it's
needed to"
* "proof of any servers misbehavior" should be "proof of any server's
misbehavior"

The abbreviations uint32 and uint64 are used a number of times without
explanation. While their meanings should be obvious to any experienced
programmer, they should be explained. "Unsigned 32-bit integer in
little-endian format" should suffice.

The message format was a bit confusing at first. A figure in Section 4
would have made the text easier to understand.

While Section 4 is very clear on how uint32s are converted to and from
byte strings, the same is not true for longer byte strings. I was a bit
confused about how to parse longer fields, such as public keys and
signatures, and about how pass the signed tags to the verification function.

Section 4 contains the phrase "Exempli gratia". Please change this to
"For example," to improve readability.

Section 5.1 states that request packets must be at least 1024 bytes. I
assume the reason for this requirement is to prevent amplification
attacks. If so, this should be stated explicitly in either section 5.1
or in the security considerations. Also, there should be a requirement
that servers MUST ignore request packets that are shorter than 1024 bytes.

The PAD tag key is encoded as PAD\xff, while the SIG tag key is encoded
as SIG\x00. For consistency, this should be changed so that both are
terminated with \x00. Additionally, terminating the tag keys with the
NULL character will make displaying them easier on many platforms.

Section 5.2 is hard to read. My suggestion is to give each tag its own
subsection. For example, the one on SREP could read:
"SREP is a parent tag in Roughtime format. It contains the ROOT, MIDP,
and RADI tags."

Nit: The first sentence in Section 5.2 is comma spliced.

In Section 5.2.1, the text "a Merkle tree using SHA512 as described when
we reach the PATH and INDX blocks" should be changed to "a Merkle tree
as described in Section 5.2.3" (or whichever number the description will
be in).

I can't find the format of RADI in the draft. It appears to be uint32.

It appears that there can be up to 32 members in the PATH array, but
this limit is not stated anywhere. With that many members, the PATH
array alone will be 2048 bytes in size. This could enable amplification
attacks and must be addressed. Furthermore, the path MTU on the public
Internet is normally 1500 bytes, which would require packet fragmentation.

Here's a tag tree with the tags' sizes in bytes:
[Header]  5*8 = 40 bytes
SREP      3*8 = 24 bytes
   * ROOT       64 bytes
   * MIDP        8 bytes
   * RADI        4 bytes
SIG             64 bytes
CERT      2*8 = 16 bytes
   * DELE 3*8 = 24 bytes
      - MINT     8 bytes
      - MAXT     8 bytes
      - PUBK    32 bytes
   * SIG        64 bytes
INDX             4 bytes
PATH          n*64 bytes

Except for the PATH tag, the sizes of the tags in a Roughtime reply are
fixed. Thus, with zero PATH members the minimum message size is 360
bytes. With PATH size (n) equal to 32, the maximum message size is 2408
bytes. The message size could be contained within 1024 bytes by limiting
n to 10. I haven't studied the Merkle tree structure in detail, so I
don't know if that's possible or what effects it would have.

Section 5.2.3 should be split into three sections: two describing the
INDX and PATH formats and one describing the Merkle tree data structure
and how the SREP ROOT is verified.

Section 5.3 is very clear and easy to understand.

I agree with Daniel Franke re Section 6.

Is the purpose of the JSON format mentioned in Section 7 to exchange
proofs of server cheating?

I don't understand the purpose of the grease described in Section 8.

The servers' public keys in Section 9 should all be in the same format
to simplify implementations.

The key for roughtime.int08h.com has been truncated. The correct key in
base64 format seems to be AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE=.

Nit: "hexidecimal" in Section 9 should be "hexadecimal".

Section 11 should include a request to IANA for a UDP port assignment.

Section 11 should include a request to IANA for a new registry for
Roughtime tag keys. Each assignment could include: the tag name (four
bytes), whether it is a parent or leaf tag, the data format/stride, and
a reference (i.e. RFC and section).

Roughtime is, like all other network time protocols, vulnerable to delay
and replay attacks by adversaries that control all or many of the
network paths to the client. This should be elaborated on in the
security considerations.

I haven't gone through the list of references in detail, but it seems to
me that some of them should be normative instead of informative.

Thank you for submitting this draft. I support its adoption by the
working group.

I hope any of this was helpful...

Kind regards,
Marcus Dansarie



On 2019-02-08 23:11, Aanchal Malhotra wrote:
> Hi All,
> 
> We have put together a draft for Roughtime. We encourage folks here to
> have a look at the draft and see if they think that there is a value in
> adopting/implementing it and would be interested to do so.
> 
>  https://tools.ietf.org/html/draft-roughtime-aanchal-00
> 
> Best,
> Aanchal.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>