Subject: [Ntp] some comments on the NTS4NTP-Draft09

From: Martin Langer <[email-masked]>
Date: Fri, 11 Aug 2017 11:34:54 +0200

Hi all,

At first, I wanted to tell you briefly that the new NTS implementation will start next week. I have some points/comments on the NTS4NTP-Draft09 that I wanted to mention in this way. Therefore, the content is primarily directed at Daniel Franke.
In advance, I'm in Japan for the next 3 weeks and will probably not be able to respond to comments or emails. I ask for understanding.

=================================================================================
NTS4NTP-Draft09
=================================================================================

1. confusing term "ntp/4"
============================================================

page 10 (chapter 5.1.5, 2nd section):
-----------------------------------------
[...] If the NTS Next Protocol Negotiation record offers "ntp/4",this record MUST be included exactly once. [...]

page 11 (chapter 5.1.5, 4th section):
-----------------------------------------
[...] and the server accepts the "ntp/4" protocol in its NTS Next Protocol Negotiation record [...]

page 11 (chapter 6.1, 1st section):
-----------------------------------------
[...] Following a successful run of the NTS-KE protocol wherein "ntp/4" is selected as a Next Protocol [...]

remark:
-----------------------------------------
"ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter 8):

[...] IANA is requested to allocate the following two entries in the Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E 0x74 0x70 0x2F 0x34 ("ntp/4") [...]

But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for 'Network Time Protocol version 4'; see table at page 21) and not the term 'ntp/4'. This can confusing some readers.

2. Network Byte Order / Host Byte Order
============================================================

page 8 (chapter 5, 5th section):
-----------------------------------------
[...] Record Type: A 15-bit integer in network byte order (from most-to-least significant, its bits are record bits 7-1 and then 15-8). [...]

remark:
----------------------------------------- 
Why 7-1 and then 15-8? Are we use the Little Endian format for the 'Record Type' only or for the whole record? Why we don't use Big Endian?

3. general comment
============================================================

page 12 (chapter 6.1, 2nd section):
-----------------------------------------
[...] The per-association context value SHALL consist of the following five octets: The first two octets SHALL be zero.[...]

remark:
----------- 
My first thought was: why? At first it was a magic number for me. The solution is here: chapter 5.2: 
[...] and MUST begin with the two-octet Protocol ID which was negotiated as a Next Protocol. [...]

I think this should be mentioned again or referenced to the corresponding table (chapter 8).

4. general comment
============================================================

page 13 (chapter 6.5, 2nd section):
-----------------------------------------
[...] This length requirement serves to ensure that the response will not be larger than the request, in order to improve timekeeping precision and [...]

remark:
----------- 
Does it really improve the timekeeping? I think the idea is to reduce the asymmetry if the request and response message have the same size. 
But client and server may have different performance and therefore the processing speed per NTP Package is different too. ...it's just a thought

5. alternative proposal
============================================================

page 20 (chapter 8, 1st section):
-----------------------------------------
[...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive [...]

better?:
----------- 
[...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 inclusive [...]

....not 16 bit, because we use a critical bit in our records (first bit)

6. some problems with 'The NTS Authenticator and Encrypted Extensions extension' (page 14, chapter 6.6)
============================================================

field description:
-----------------------------------------
'Nonce lenght': We should mention that the value is to be interpreted as 'unsigned int'.

'Nonce': At first I had some trouble to understand where the nonce comes from and which length we use. Now I know it, but maybe we should add some more information to this field.
perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter 3.2). [...]

'Chipertext': Some readers (students in my team) had difficulties to understand this field. All of them thought, that this field contains an encrypted version of the whole NTP package. And this is wrong. I think the problem is this line: [...] authentication tag in addition to the actual ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then this leads to strong understanding problems at this point, since the terms 'authentication tag' and 'ciphertext' seem not known. I think we should add a reference (RFC 5116 --> AEAD) or some information about this terms ('authentication tag' is like a MAC and 'ciphertext' contains optional Extension Fields and can be absent if no Extension Fields are encrypted.). Maybe confuses the field name 'Chipertext' too.

'Padding:' This line: [...] so that implementations can unambiguously delimit the end of the ciphertext from the start of the padding [...] can be difficult to. In the beginning I did not know how this should work. We should say that implementations can read the last octet of this extension content, to find out how big the padding is.

Furthermore we should change this line:
[...] requirement that (in the absence of a legacy MAC) extensions have a total length in octets (including the four octets for the type and length fields) [...]

in this:
[...] requirement that (in the absence of a legacy MAC) NTP extensions have a total length in octets (including the four octets for the type and length fields) [...]

--------------------------------

[...] P: The plaintext SHALL consist of all (if any) extensions to be encrypted. [...] 

Which format? Typical NTPv4 Extension Fields or another format? We should define that. We should also mention that only this content is encrypted (not the content of parameter 'A'). 
If we don't want encrypt anything (default case), then this parameter is empty.

============================================================

Please let me know if you have problems to understand my *english*.

Best regards,
Martin