[Ntp] some comments on the current NTS draft (nts4ntp-12)

[Martin Langer <[e-mail]>]

Hello together,

I have read the current NTS draft and some comments. A PDF version of 
this draft (including my comments) is temporarily available on my git 
repository.
Link: 
https://gitlab.com/MLanger/nts/raw/develop/Documentation/draft-ietf-ntp-using-nts-for-ntp-12-pre%20-%20comments%20(ML).pdf


1.  (Page 6; Figure 1)
-------------------------------------------
I think we should move the digits one character to the right.


2. (Page 12; Section 5.1)
-------------------------------------------
We should add one more information about the C2S/S2C keys:
The draft does not specify the length of these keys because the lengths 
results from the negotiated AEAD. However, for an implementor which is 
not familiar with TLS it would be helpful if the draft would provide an 
appropriate explanation.
Recommendation: Add explaining language to the draft. E.g., "The length 
of the extracted keying material (c2s and s2c) results from the 
negotiated AEAD algorithm. For AEAD_AES_SIV_256 the length of the keys 
are 256 bit, respectively."


3. (Page 15; Section 5.6)
-------------------------------------------
New calculation of the padding bytes:

I don't understand why we need this.

Example:
N_MAX: bigger than 16 (e.g. 64)
N_len: smaller than  16 (e.g. 8, for whatever reason)

Calculation of the AEAD-ExtField size (current case):
AEAD_EF_size = Nonce length (2 bytes) + Nonce (>=1 bytes ) + AEAD output 
(>=16 bytes ) + Padding (>=1 bytes )

with N_len=8 and AEAD_out=16 (no encrypted content; only AuthTag):
AEAD_EF_size = 2 bytes + 8 bytes + 16 bytes = 26 bytes .

...so we need 2 padding Bytes to achieve the four-octet boundary 
(additionally we reached the min size for the EF)
final AEAD_EF_size = 28 bytes


with the equation:

PadBytes = MAX(MIN(N_MAX, 16) - N_len, 0) + 4

PadBytes = MAX(MIN(64, 16) - 8, 0) + 4
PadBytes = MAX(16 - 8, 0) + 4
PadBytes = MAX(8, 0) + 4
PadBytes = 8 + 4
PadBytes = 12


new AEAD_EF_size = 2 bytes + 8 bytes + 16 bytes + 12 bytes (PadBytes) = 
38 bytes.
This is bigger and we need 2 more padding bytes to achieve the 
four-octet boundary.



4. (Page 15; Section 5.6)
-------------------------------------------
"This constraint ensures that servers can always use an adequately long 
nonce without causing the size of their response packet to exceed the 
size of the request packet."

Is it possible for the server to generate a message that differs from 
the size of the request?  ...and how?
I mean... AEAD algo and nonce are the same for client and server. The 
AEAD EF have always the same size.
I'm a bit confused



5. (Page 16; Section 6)
-------------------------------------------
2 small typos:

- [...] We emphasize also that " encrypted" means [...]    --> space in 
" encrypted"
- [...] body of a NTS Cookie extension [...] --> an NTS Cookie?



6.  (Page 18; Figure 3)
-------------------------------------------
small gap in the picture:

"Server -------- --+---------------+-----+----------------------->" --> 
space


7.  (Page 19; Section 7)
-------------------------------------------
"Servers SHOULD periodically (e.g., once daily) generate a new pair 
(I,K) and immediately switch to using these values for all 
newlygenerated cookies."

Should we define a minimum limit? Rotation interval >= 21600s (6h)?



8. (Page 19; Section 7)
-------------------------------------------
"A recommended concrete implementation of this approach is to use HKDF 
[RFC5869] to derive new keys, using the key’s predecessor as Input 
Keying Material and its key identifier as a salt."

maybe we should add some more information:
Use of HKDF makes it simpler to keep master keys in sync across 
load-balanced clusters. They can all update their keys on their own via 
a deterministic ratchet rather than have to communicate with each other.
...and: 'Salt' and 'context' are software defined



9.  (Page 25; Section 9.1.4)
-------------------------------------------
refreshing the dates :)





10.  (Page 26; Section 10.1)
-------------------------------------------
[...] Due to the [RFC7822] requirement that extensions be padded and 
aligned to four-octet boundaries, response size may still in some cases 
exceed request size by up to three octets. [...]

um... ok. But in which cases is it possible?



best regards,
Martin Langer

-- 
Martin Langer, M.Eng.
Labor Datentechnik
Labor Design Digitaler Systeme

Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel -
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Tel. : [phone]
Fax  : [phone]
Mail : [e-mail]
Web  : http://www.ostfalia.de/cms/de/e