# NTP Virtual Interim Meeting Time: Dec 18, 2018 4:30 PM UTC Participants: Dieter, Karen, Daniel, Marcus, Martin, Tal, Miroslav, Denis, Kristof, Danny, Watson Ladd, Rich Salz, Aanchal, Harlan Minutes: Dieter 1. Administrative and Agenda Bashing ------------------------------------- - Put item "Time Security beyond NTS" at the end of the agenda Note Well by Karen Nobody opposed to record the meeting 2. TICTOC quick document status (documents we hopefully won’t need to discuss) ------------------------------------------------------------------------------- Two outstanding documents: (i) Yang model for 1588 is in the second IETF LC (status ) (ii) 1588 Enterprise profile WGLC is complete and ready to go to the IESG. There is still the pOpen issue with the availability of the underlying IEEE document. If both docs are finished the WG shall be closed. 3. NTP quick document status ----------------------------- - MAC code for NTP is finish, the write-up must be finished - BCP is in balloting with the IESG (probably one final round for small editorial changes). Karen thank the authors of these two documents for their work, especially Aanchal and Denis. 4. Network Time Security for the Network Time Protocol (WGLC wrap-up) ---------------------------------------------------------------------- - WGLC finished for the document. - Majority of the reviewers are in favor that this document should go forward - Some comments have been made and have been considered in the new version 15 released on Monday. - Summary of the changes * The Security Consideration's section now recommend that a client should not automatically perform an key exchange when the server certificate expires. If the client has received valid time responses and therefore cookies that lay within the validity time of the certificate it should continue using the cookies. More information by Marcus. * A sentence has been added that higlights the importance of ciphersuits that provides forward secrecy. * The language witch describes the behavior of the client if the NTS-KE exchange fails has been enhanced (comment by Miroslav) * Occurences of ‘bytes’ have been replaced by ‘octets’ * In the section Security Considerations: Marcus inserted a subsection on a NTS stripping attack. * Several tyos have been fixed and some editorial changes have been done. - Not considerd comments * TLS 1.3: the authors agree that it is not advisable to enforce TLS 1.3 at this time. The current language allows an implementation to provide 1.2 or 1.3 or both. * Heiko Gerstung proposed to request an port assignment for NTS protected time synchronization messages. This still is an open point. - Daniel: does't agree with the Marcus's change that an client shall not automatically perform an key exchange if the servers certificate expires. The right solution is to do the KE handshake at a random point prior to the expiration. - Watson: why should an expiration enforce a new handshake? - Daniel: Discussion started about the chicken-and-egg problem when the client starts the association and has no idea about the current time and cannot verify the certificate's validity window. One recommendation was not to accepted an initial time outside the certificate's validity window. Maybe it is sufficient that once the client got a time from the server that is inside the validity window and what is later received is consistent with what is received originally just go ahead accepting it after the certificate expiration. - Marcus: If the client is doing the KE the certificate guarantees that the client exchange keys with whoever ist in control of that domain with the certificate at that point. If the certificate expires the client can still safely assume that the person who was in control of the domain at the initial KE is still the person who the client is doing time sync with. - Watson: that is the best you could do. - Karen: Daniel, do you suggest a clarification to the text? - Daniel: text is reasonable but want to have requirement's language - Marcus applied requirement language - Dieter changed that because this text is within the Security Consideration section - Karen: Security Consideration section generally do not have 2119 language - Daniel: have seen a lot of exception to that - Rich: if the protocol should something enforce it is usually in the text and not in the Security Considerations. - Kristof: ask which scenario causes a KE exchange. - Daniel: Reason for a new KE is either receiving a NTS NAK or running out of cookies - Kristof: there is a scenario you never do a KE - Daniel: Because of this text people could do implementation mistake and never do a new KE after the certificate expiration if the client does not receive a NTS NAK or never running out of cookies. - Kristof: seems to be worrisome - Rich: Suggest to add a sentence in the Security Considerations that says, this might happen e.g. if the server's certificate expires but old cookie still exist. - Daniel: Right, we should also explicitly state the motivation not doing immediate handshake which is preventing from accidental DoS attacks. - Karen: This should be solved by Marcus, Rich, Daniel, Watson, and Kristof - Karen: What about Heiko's request about the TCP and UDP assignment request? - Dieter: Meinberg plans to implement NTS as a daemon separated from NTPD. Since ntpd requires UDP/123 the NTS daemon shall be addressed via an alternative port. Meinberg would like to have an UDP port assignment for NTS protected NTP messages. - Watson, Daniel, Karen, Harlan, Danny: some clarification about Meinberg's intention followed by a discussion. Concerns about NTP rulesets in firewalls, etc. - All: General consensus that the NTS document shall require a port assignment for the key exchange but not for the exchange of time messages. - Rich points out, that this can be done afterwards also. - Karen summaries: - There is consensus in the WG to go forward with this document - Harlan has following issues * EF type form * Scoping of the draft to be client-server mode only - we are open to expand the scope in the future - one more editing necessary before submitting to IESG - Daniel: the remaining issues can be summarized in the shepherd writeup - Karen: will send the shepherd writeup to the mailing list so that the group can help that it describes the remaining issues properly - Sam Weiler propose that we follow Harlan's suggested values for the EF codes for the NTS EF unless this is demonstrated to be harmful - Daniel opposes putting any text in the document requesting those code. If we submit the document as it is we can talk to IANA out of band and ask them to assign these specific code once. - Karen is happy to do an early allocation request to IANA for those specific codes. This does not imply generic structure until the EF staff is updated - Sam agrees that this in a one-time early allocation request. His intention is to leave open the possibility that Harlan EF draft will get consensus. - Karen would like to work with Sam to send a very concise mail to the WG that that says we plan to add this to the EF document so that the WG can determine that this is not harmful. 5. Planning for NTS interoperability testing --------------------------------------------- - Karen: various implementations are in progress - Karen: will send to the WG the address of a mailing list for discussions on and interoperability testing of NTS implementations - Karen: A NTS hackathon event is planned or IETF 104 (Prag). Strongly encourage the use of the mailing list to plan for the hackathon event - Watson: We might be able to get a public server for interoperability purposes up 6. Network Time Protocol REFID Updates (WGLC wrap-up) ------------------------------------------------------ - Karen: we did a WGLC on this document. Not many responses and some objections - Karen will work together with Harlan offline to expand on the objections from Miroslav and Steven. - WE have to issue another WGLC to get more consensus - Action: Take this document out of WGLC status and back to working group document status. 7. NTP Interleaved Modes (WGLC wrap-up) ---------------------------------------- Karen: we had a WGLC on this document Miroslav: status of WGLC - quite some comments - new version of the draft has been uploaded to address these comments. There have been no changes of the protocol itself. The updated draft improves on the goals of this draft. Why we need interleave mode? How it improves accuracy? Why we don't use follow-up messages? The Security Considerations section is also updated in regard to DoS attacks. - Harlan is particularly concerned about clients which receives interleave responses although they don't expect that. Harlan will investigate this. - Miroslav: that should not happen - Harlan: if this does not happen Harlan has no objections - Harlan still want to discuss with Miroslav to have the option for a follow-up messages in order to avoid that the server has to keep state - Karen: Harlan and Mirsolav should work out there issues until mid January - Karen: this document has passed WGLC pending resolution of this one issue 8. NTP Client Data Minimization (WGLC wrap-up) ----------------------------------------------- - Karen: - this document is in WGLC - no update since Sep. 2018 - Aanchal: - most of the issues are addressed - Harlan has some issues, for which he want to send in more detail - Harlan: I have more stuff to say about this. - Daniel: Harlan claims that data minimization can be harmful in some circumstances but without specifying the circumstances. That needs some elaboration. - Harlan: Miroslav already pointed out that zero timestamp is problematic, poll interval is important around a leap second event. - Harlan: mentioned upcoming code which will not work with data minimization - Karen: pointed out that we cannot lock this draft because of upcoming code that is neither described nor published - Karen: ask Aanchal to review all comments regarding this draft and to send a mail to the mailing list which specifically complies the open issues and solicit input for those issues - Watson: I see that data minimization is mentioned in the Security Considerations section of NTS but I don't see that it is required to be implemented by clients. - Daniel: It isn't required. But it is still a reference we are not willing to remove. NTS cannot be published until data minimization is published. - Danny: A dumb client will ignore any auxiliary information from the server. For such clients it doesn't matter what you put into this document. - Miroslav: If a client supports the adjustment of the poll interval around a leap second by following the suggestion of the server it can ignore this specific part of the data minimization. No conflict here. - Karen: changes here request to Aanchal: Question to Harlan: when will you send your comments to the mailing list? - Harlan: It depends. I will do my best. Will turn this into something more collaborative. - Harlan: suggest to add more guidance about in which situation minimization can be applied or cannot be applied. - Daniel: is ready to consider the language of the draft. So far he isn't persuaded of any case where you don't want to minimize. - Daniel, Watson, Harlan, Danny: some discussion about the necessity whether or not the client has to send his polling interval in the context of KoD and client-server interleave mode - Daniel: ask Harlan to publish a document about the new polling interval mangement. This document can explicitly describes situations in which the polling interval management and data minimization conflicts. - Karen ask Harlan again to send actionable suggestions to the mailing list regarding this document. - Karen ask Aanchal to summarize the results thus far - Karen points out that we might add some generic language to the draft. But the IETF has a long history in publishing RFCs that updates older RFC. She recommends to publish this draft for the situation that exists now and not for a situation that might come up in the future. - We have to postpone the final decision on forwarding this docuement to the IESF until Harlan's and Aanchal's action have been completed. 9. Leap second file -------------------- - Karen: If we need to have the leap second file maintained on www.ietf.org we need to have a document that specifies the rules for maintaining it. Currently the IETF has a trouble ticket issued on this file with no clear indication what the IETF process is to manage this file. - Danny: ask who is responsible for the leap second. - Karen: Responsible is the IERS (International Earth Rotation and Reference Systems Service) - Denise - IERS is responsible for the announcement of leap second - The national metrology institutes are responsible for dissemination of this information (somehow) - The BCP contains three different links to this file - the file is on the IETF website because this file is also included in the timezone database maintained by IANA (BCP 175) - Karen: One of the NTP implementors was saying that their code points to the the file at the IETF website. Therefore they want to have it maintained. Either it is not needed by anybody than the IETF website team does not have to worry about it or it is needed than we have to indicate this and have to inform who maintains it. - Denis: Recommend to maintain the link to the TZ database. There is already a RFC about how it is maintained. - Harlan: the ntpd distribution is using the link to the IETF website. But it could also be adjusted. - Daniel: nothing in RFC 5905 presumes the existence of this file in any particular place or format - Denis: RFC 6557 (BCP 175) describes the maintenance of the TZ database. - Karen: We will see that we describe what we want to do with the file. Consensus is that it needs to be documented, possibly moved to IANA. 10. Guidelines for Defining Packet Timestamps (WGLC wrap-up) ------------------------------------------------------------- - Karen: WGLC finished - Karen (2 objections, not many reviews and comments) - Tal: two main comments which have been addressed after some iterations. The comment from Denis is also considered. - Tal: draft is pretty stable - Karen ask if there is any opposition to move this draft to the IESG - Watson want to have a look at it and send a review to the mailing list - Tal also ask people to send there opinion on this draft - Karen will send a note to the mailing list and request comments and opinion on this draft in oder to be able to forward it to the IESG 12. AOB (Any Other Business?) Time Security beyond NTS ------------------------ - Watson: want to promote something like Roughtime. The idea is to sacrifice time synchronization accuracy in order to be able to track servers and that they don't provide clients with false time. Realized by providing signatures of timestamps. Want to see this more widely deployed. - Daniel: is the idea to recommend Roughtime in particular? - Watson: has some problems with Roughtime especially the smearing of the leap second. - Watson: is interested in working together with someone on something like Roughtime. - Daniel: is interested in an outline of such a document - Aanchal has a couple of concerns about Roughtime which she is willing to share - Karen to Watson: please send some pointers to the mailing list about Roughtime - Next Interim week of 21st January