NTPWG INTERIM MEETING 2017-12-12 PARTICIPANTS: Karen O'Donoghue, Dieter Sibold, Ragnar Sundblad, Kristof Teichel, Miroslav, Rob Nagy, Harlan Stenn, Tal Mizrahi, Dave Mills, Sam Weiler, Daniel Franke, Denis Reilly, Rich Salz, Richard Welty, Martin Burnicki, Doug Arnold, Stevo Administrative and Agenda Bashing (Chairs) Karen presents the Note Well NTP WG Agenda Karen presents the agenda. No agenda bashing. Network Time Security https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp - Daniel: Martin Langer prepared flow diagrams for NTS. However, they are to detailed to be incorporated into the specification. It is intended to reduce them to be appropriate for inclusion. Hopefully, this can be done before Christmas. Martin Langer's flow diagram will be made accessible at NTS's GitHub repository. - Dieter: Kristof started a mail thread on the NTP WG list to discuss some of the comments we've got from Sharon during the last WGLC. However, up to now there have been no feedback. - Karen: How close we are to a new WGCL? - Dieter: A new version of the document might be available in January 2018. - Daniel suggest to leave the document in a stable state until the Hackathon in March and wrap-up the WGLC until we have a proof-of-concept. - Karen's summary: a new version in January, a Hackathon meeting in March and after that finalization of the document. - Kristof: A normative issue might be the request to make the cookie format more normative. NTP Interleaved Modes https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes - Miroslav uploaded a new version which considers Kristof's comments. - Servers do not need to save state for clients which don't use interleave mode. - Changes are introduced to the symmetric mode - Karen: WG adoption call will be issued. Anybody on this call who a opposed to WG adaption of this draft? Nobody. NTP Extension Fields Network Time Protocol Version 4 (NTPv4) Extension Fields draft-stenn-ntp-extension-fields-04 - Harlan: this is out for a couple of years old. RFC 7822 is overreached and badly designed. The goal of this document is to maintain compatibility with old implementations of NTPv4. Incorporates useful new flag bits. - Karen: this version of this draft is from 4th Nov. Are there question for clarifications of this draft? - Danny points out that stealing bits from the EF for other purposes is a really bad idea. From a protocol point of view this will cause conflicts. - Harlan points out that bits are taken from the EF field type field only. - Danny: These bits are conflicting other EF related documents. - Exchange between Harlan and Danny about the evidence of this claim. Danny points out that he already provided a description of potential conflicts to Harlan. - Karen: Are there other questions for clarification? - Daniel: What is the intension of the legacy MAC required bit? - Harlan: RFC 5905, Sec. 7.5 states clearly that if an EF is presented it must be protected by a MAC. RFC 7821 is the only other EF related RFC which states that this EF cannot be protected by a MAC. This draft introduce the legacy MAC required bit in order to provide efficient parsing of incoming packets. - Daniel ask what will happen of a MITM will alter this bit. - Harlan: That depends. If an association is meant to be MAC protect the packet would be dropped. - Kristof: If the association expect a MAC why do I have the bit to signal this? - Harlan: This is for the parser to increase efficiency. - Danny: Efficiency of the parser is not the point in a protocol. - Somebody: This sounds like a downgrade attack - Danny: Two EF with different settings of the bit flags will cause conflicts - Harlan asks how often this is going to be happened - Danny: Anybody who wants to perform a attack is going to do this. - Harlan states that this might happen in the Internet but within a enterprise network the network control mechanisms will protect against such attacks. - Kristof: If there no attacker why requiring a MAC? - Harlan: Because 5905 requires MAC protection for any packets with EF and 7821 requires that there is no MAC. - Tal: The sentence in 5905 (Sec 7.5) who requires a MAC if the packets contains a EF is updated by an erratum. - Harlan claims that this erratum is done wrong. - Tal points out that right now this erratum is valid and it doesn't state that there has to be a MAC. - Somebody ask for clarification what specs are addressed by the RFC numbers. Harlan provided a short overview of 5905, 5906, 7821. - Tal: Harlan's draft has two main messages. The first: changing the parsing logic, basically to cancel the minimum 28 byte EF length. Secondly: taking some of the bit of the field type and allocating these bits for different purposes which would probably require changes in the IANA registrations. There are two separate questions of whether the first or second or both parts are required. - Danny supports Tal's statement. - Karen ask for further opinions - Martin Burnicki acknowledges that Harlan's proposal is more detailed and clearer and therefore prevents implementers to provide buggy code. Does it make sense to have a requirement that forbids the intermix of old and new EF? - Harlan doesn't think that this is necessary because he don't expect that RFC 5906 will be around for much longer. NTS will be used for packet protection and the extended information EF - if the document will pass - for the TAI-UTC offset. - Daniel states that the proposed parsing algorithm leaves an acknowledged ambiguous case and leaves it to the the implementers how to interpret this case. Daniel does not think this is acceptable for the WG to publish. Protocols need to be unambiguous. - Harlan disagrees. The proposal describes how to avoid unambiguity. It is the choice of the implementation and deployment people to avoid unambiguity. - Daniel states that this approach form his point of view is fundamentally inacceptable. - Harlan again disagrees and insists on the possibility for a local choice. - Daniel points out that two implementations with different policy choices are unable to interoperate. - Harlan agrees. But from his point of view this will happen very rarely. - Martin compare this approach with the acceptance rules of ssh keys by SSH. - Harlan again addresses the small likelihood for unambiguity if the parsing rules of his proposal and what is specified in 5906 are followed. - Tal suggest that Harlan's draft should explicitly require that any symmetric keys should have a keyid which is less than 64 k. Currently it does not formulate this as a requirement. - Harlan is not sure if this is necessary but it could be done. - Tal: otherwise he agrees with Daniel that if people apply keyid larger than 64k it won't work. - Harlan again stresses the small probability of such an collision. - Karen ask to incorporate Ta's suggestion. - Harlan will check if this is possible - Karen: any additional questions for clarification? - Miroslav: Is the last EF draft a requirement for this draft to avoid the unambiguity in parsing? The example parser doesn't seem to use it. Is it a requirement that the implementation has to understand the last EF draft? - Harlan: no - Danny: the last EF draft should only state that there is an legacy MAC and its length is x. That should it be rather the current proposal. - Harlan disagrees. - Discussion between Danny and Harlan of the usefulness of the last EF draft. - Karen interrupts the discussion. - Karen comes back to Martin's point about legacy vs new EF. It is planned to obsolete RFC 5906. - Daniel: the IETF way is to publish a new informational document that describes the problem of the old document and states don't use it anymore. - Karen: any other questions? - Kristof: Why is the legacy MAC required bit necessary? - Harlan stresses that is proposal is consistent with 7821, 5905, 5906 and 7822. Harlan claims that 7822 introduced a big hole in not requiring a MAC if a EF is present. - Kristof asks how is Harlan's proposal better than 7822? He claims that the introduction of the MAC required bit does not improve anything. - Some discussion between Kristof, Harlan, Martin, Daniel and Danny about this issue. - Kristof does not feel that his questions is answered. - Karen has the impression that persons talking past other and questions are not answered. - Karen: This proposal is an individual submission. The next step is a call for adoption by the WG. Who is in favor for adopt this as a WG draft? Two persons are in favor for adaption. - Daniel suggest to submit a call for WG adoption to the WG mailing list. - Karen will do the call and ask for short and precise comments. - Harlan ask if this call is for the EF draft only? - Karen: Yes, because of its importance to 7822. - Harlan points out that his other EF related drafts depend on this draft. - Daniel replies that some of the EF draft does not fundamentally depend of this draft but also can be adapted to 7822. - Discussion with open end on the dependence of EF drafts and Harlan's proposal between Daniel and Harlan. Network Time Protocol Extended Information Extension Field draft-stenn-ntp-extended-information-01 This EF transports extra information such as: - TAI-UTC offset - Interleave mode - maybe leap second correction Network Time Protocol I-Do Extension Field draft-stenn-ntp-i-do-03 - What am I be able to process? Network Time Protocol MAC/Last Extension Fields draft-stenn-ntp-mac-last-ef-01 - Includes either a MAC or a signature or or a set of MACs in broadcast mode - Last extension field Network Time Protocol Suggest REFID Extension Field draft-stenn-ntp-suggest-refid-02 - no-you, - IPv6 hash value Karen will send a single email and ask for comments of the different EF drafts. NTP Correction Field draft-mlichvar-ntp-correction-field-01 - Miroslav: There is a new version of the correction field draft. It addresses some of the comments raised by Tal. Network Time Protocol REFID Updates https://datatracker.ietf.org/doc/draft-ietf-ntp-refid-updates/ Open work items (No updates since IETF 100): Message Authentication Code for the Network Time Protocol https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac - will be an update coming up shortly NTP Client Data Minimization https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization - WGLC NTP BCP https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp - Deny ask for refreshing the draft. - Karen: Yes, this is appreciated. A YANG Data Model for NTP https://datatracker.ietf.org/doc/html/draft-ietf-ntp-yang-data-model - no updates Guidelines for Defining Packet Timestamps (Mizrahi) https://datatracker.ietf.org/doc/html/draft-mizrahi-intarea-packet-timestamps/ - no updates. An update should be presented soon. On Implementing Time draft-aanchal-time-implementation-guidance-00 - Kristof added as editor. TICTOC Agenda: Open work items No updates since IETF 100 IEEE 1588 Enterprise Profile https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile - no updates YANG data model for IEEE 1588v2 https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang - no updates Next steps - Updates for NTS and preparation for the Hackathon - Extension fields - An additional Interim in January (mid to late January) - Are there preferences between Webex and ZOOM? Daniel would prefer Meetecho. Karen not sure how to use it between meetings.