From aanchal4 at bu.edu Sun Sep 3 19:09:51 2017 From: aanchal4 at bu.edu (Aanchal Malhotra) Date: Sun, 3 Sep 2017 21:09:51 +0200 Subject: [ntpwg] Comments on NTS - Aanchal Malhotra Message-ID: Hi, Sorry for the late review. I am unwell and so away from emails. I think the document is great but few sections remain inadequately explained. I would like to do another pass and may be even have another WG call before going forward. Please read my following comments. *Section 1.1* Aren't the objectives of NTS different for different modes? e.g. 1) The following objective is not true for client/server mode, since the server does not have this privilege. " *Replay prevention: Implementations may detect when a received time synchronization packet is a replay of a previous packet."* 2) The usage of the terms client and server in the following objective is confusing. Does it refer to NTP client/server mode? Does it refer to any implementation? "*Request-response consistency: Client implementations may verify that a time synchronization packet received from a server was sent in response to a particular request from the client*." Similar problems with the 'Unlinkability' and 'Scalability' objectives. I think it would be worth stating separately the Objectives of NTS for different modes. And make use of the terms client and server to only refer to NTP's client server mode participants. In fact the first para of section 1.2 could be used to justify the different objectives of NTS for different modes and could be placed before/in section 1.1 *Section 1.2* "*it is harmless for servers to process replayed packets*" I do not agree with the statement above. In addition to Sharon?s objection, in NTS, the server can be DoSd in terms of resources by replaying query packets because it has to do more work than normal NTP. Minor comment: Section 1.2 The last and second to last paras are 2 parts of the same thing. Putting them in 2 points makes it more readable. *Section 4.* I feel like this section requires more discussion on the length of sessions. Like what is the typical frequency of symmetric peer exchanges and correspondingly what is the typical length of a DTLS session? When will it time out? How often do the peers have to re-establish DTLS session? How do they know? Similar questions for control mode and client/server mode. Overall, this section needs more explanation. ?*The two endpoints carry out a DTLS handshake in conformance with Section 3, with the client offering (via an ALPN [RFC7301] extension), and the server accepting, an application-layer protocol of "ntp/4"*. Again term client/server is overloaded. This is supposed to be DTLS client and DTLS server and not NTP mode3/4 client server. Also, add ?First? in the beginning of sentence. *Section 5* The interpretation of critical bit C seems confusing. How is the figure 2 parsed by the client? The interpretation of C is Record Type dependent. Why in section 5.1.5 "C is MAY and not MUST? How is this bit interpreted when it is 0 or when it is 1? Also, in section 5.1.6 "C SHOULD NOT be set". Again, what does the client do if he finds it set? IMO, this section is very high level description and not very fluent from implementation point of view. As written now, it is very difficult to follow. May be we can have a table with all possible combinations of C and record types and the corresponding action taken by client or the server. *Section 6* ?*Upon receiving an NTS-protected response, the client MUST verify that the Unique Identifier matches ??? which sent the NAK and initiate a fresh NTS-KE handshake.*? This section is understated and requires much more detailed explanation. The order in which client performs the checks and the corresponding changes it makes to the internal state variables is important to mention as this has lead to several implementation flaws in the past. For instance, 1) If the UID match passes, the client checks for crypto. Then there are two cases: a) If crypto is fine, client processes the packet and stops listening for any response corresponding to this UID. b) If crypto fails, it does not process the packet and stops listening for the response corresponding to this UID. 2) If the UID match fails, the client should not check for crypto. AND must still keep listening for the packets corresponding to the stored UID. (Otherwise an easy off-path attack.) This is just an example. There are several other cases and it is IMPORTANT to mention the state variable changes in EACH case. We should discuss/talk about it and sort this out. Thanks, Aanchal Malhotra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ulrich.Windl at rz.uni-regensburg.de Mon Sep 4 12:50:22 2017 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Mon, 04 Sep 2017 14:50:22 +0200 Subject: [ntpwg] Q: on mode 6 packets' MAC References: <59AD4C0E020000A100027BB6@gwsmtp1.uni-regensburg.de> Message-ID: <59AD4C0E020000A100027BB6@gwsmtp1.uni-regensburg.de> Hi! While tyring to parse ntpq's mode 6 packets I found four octets of zero after padding when I expected to find a key ID. The key ID however seems the next four octets. After thinking I had made an error, I looked into the source I had (not latest,but 4.2.8p6): In contradiction to the specs I found, ntpq adds a padding in sendrequest() even if no MAC follows: if (qsize > 0) { memcpy(&qpkt.u, qdata, (size_t)qsize); pktsize += qsize; while (pktsize & (sizeof(u_int32) - 1)) { qpkt.u.data[qsize++] = 0; pktsize++; } } More surprisingly, it adds another level of padding before the digest: if (!auth && !always_auth) { return sendpkt(&qpkt, pktsize); } /* * Pad out packet to a multiple of 8 octets to be sure * receiver can handle it. */ while (pktsize & 7) { qpkt.u.data[qsize++] = 0; pktsize++; } If I don't know the specs being used for that, can someone point me to the specs, please? Otherwise can we make the implementation match the specs, please? Regards, Ulrich