Subject: [Ntp] Comments and solutions for the current NTS draft

From: Martin Langer <[email-masked]>
Date: Tue, 10 Jul 2018 14:38:39 +0200

Hello Daniel, hello Ragnar,

I have some comments and suggestions based on the current documents
(draft-ietf-ntp-using-nts-for-ntp-12 and draft-dansarie-nts-00) as well as
Harlan's statements.

================================================================================
             Comments to draft-ietf-ntp-using-nts-for-ntp-12
================================================================================

--------------------------------------------------------------
1.1  (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 developer which is not 
familiar with
TLS it would be helpful if the draft would provide an appropriate 
explanation.

So we should 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."

--------------------------------------------------------------
1.2  (Page 15; Section 5.6),  New calculation of the padding
--------------------------------------------------------------
I don't understand why we need this.

Here is an 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 authentication 
tag):
AEAD_EF_size = 2 bytes + 8 bytes + 16 bytes = 26 bytes (without padding)

...so we need 2 padding bytes to achieve the four-octet boundary 
(additionally
we reached the min size for the NTP extension field [including the NTP EF
header we have 32 bytes])

final AEAD_EF_size = 28 bytes

-------

with the new equation in section 5.6:

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.

--------------------------------------------------------------
1.3  (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... the AEAD algorithm and the nonce are
the same for client and server. The AEAD EF have always the same size. 
I'm a
bit confused.

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

....but already corrected by Ragnar in his document

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

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

....already corrected by Ragnar in his document

--------------------------------------------------------------
1.6  (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)?

--------------------------------------------------------------
1.7  (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."

We should add some more informations:
"The useage 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.

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

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

================================================================================
                  Comments to draft-dansarie-nts-00
================================================================================

I think the new ideas are good and they are easy to implement.

--------------------------------------------------------------
2.1  The separation of the NTS-KE and NTP servers
--------------------------------------------------------------
Yeah, I think we can do it. For my understanding this is a logical 
separation
and the following solutions are possible:
- NTS server and NTP server are running in the same application
- NTS server and NTP server are running in the same machine but in 
different applications (instances)
- NTS server and NTP server are physically separated and run on 
different computers

This is not a big deal, but we must define the construction of the 
cookie (it
must be normative). Actually the section 7 is non-normative. 
Alternatively, we
need to make sure that the NTS server and NTP server build the cookie in 
the same way.

--------------------------------------------------------------
2.2  Changing the requirement of TLS 1.2 to 1.3
--------------------------------------------------------------
Maybe we should do this. My current implementation works with TLS 1.2 
and 1.3.
I can easily disable TLS 1.2.

--------------------------------------------------------------
2.3  Addition of an "NTS Server Negotiation" NTS record
--------------------------------------------------------------
it's ok for me

--------------------------------------------------------------
2.4  Change of the AuthAndEncExtField extension field format
--------------------------------------------------------------
it's ok. What about compliance with the minimum length, if 28 bytes are 
required?
=> RFC 7822

--------------------------------------------------------------
2.5  servers that implement NTS to always include the "Unique Identifier"
--------------------------------------------------------------
it's ok for me

--------------------------------------------------------------
2.6   clients should store cookies on persistent storage
--------------------------------------------------------------
it's ok for me. I had already thought of something like that.

================================================================================
                          Harlan's statements
================================================================================

It looks like NTS should only be assigned only one ID for the NTPv4 
extension
fields. Umm... I'm ok with that, but we must change a bit, because 
actually we
defined 4 NTS extension fields for NTP

Here is my solution for this issue:

The NTP EF field type 0x0004 is reserved for NTS. We can define a new data
strucure for NTS messages. I call it 'Messages' to avoid confusions with 
the
TLS 'Records'. The structure is constructed as follows:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
|        NTS Message Type       |          Body Length          |
+---------------------------------------------------------------+
.                                                               .
.                              Body                             .
.                                                               .
+---------------------------------------------------------------+
|                       Padding (as needed)                     |
+---------------------------------------------------------------+

NTS Message Type: a 16-bit unsigned integer specifying the message type
                   (e.g. 'Unique Identifier', 'NTS Cookie', ...)

Body Length:      this 16-bit unsigned integer represents the length of the
                   Body without any padding or header itself

Body:             the NTS message in network byte order
Padding:          zero-padded to a word boundary (four octets) and 
conform to RFC 7822.

And in this case we should rename our extension.
-> 'NTS Cookie Extension Field' in 'NTS Cookie Message' or something.

In addition, we then need to customize some of the areas in Section 5.5 
(The NTS
Authenticator and Encrypted Extension Fields Extension Field) and make 
it clear
that encrypted extension fields mean complete NTP EFs or just the 'Message'.

best regards,
Martin

-- 
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel. : +49 5331 939 43370
Web  : https://www2.ostfalia.de/cms/de/pws/bermbach/start/kontakt_langer.html