NTP WG Interim Meeting - Boston Friday October 14, 10:00 am - 5:00 pm Chairs: Karen O Donoghue and Dieter Sibold Agenda ====== 1. Overview/summary of updates from the core security documents (explanation of the documents): draft-ietf-ntp-network-time-security draft-ietf-ntp-using-nts-for-ntp draft-dfranke-nts (no discussion planned, but included here for completeness as part of the suite of security documents thus far) draft-ietf-ntp-cms-for-nts-message Dieter presented a preliminary merged documents of the two drafts draft-ietf-ntp-using-nts-for-ntp and draft-dfranke-nts (for more details refer to the session's materials section). Decisions: 1)   What key exchange (KE) protocol to use? 1.a) Do we want to allow optional key exchange mechanisms? (Alternative KE protocols). Decision: NO. 1.b) KE for the client server mode (mode 3/mode 4):     Decisions: - TLS out of band to establish keys. then transmission of timing information is done with custom protocol from daniel's draft over UDP/123.     - smuggling DTLS KE over NTP extension fields is tabled for now.      1.c) KE and transport for symmetric peering mode (mode 1/mode 2):     Decision: TLS (alternatively DTLS) on a port other than UDP/123 to establish keys, and then timing information is carried over the TLS record layer. 1.d) KE and transport for control mode (mode 6)      Decision: DTLS on a port other than UDP/123 to establish keys. then timing information is carried over the DTLS record layer. 1.e) Open question for mode 1,2,6:      * what port to run the handshake on? 123 or other port?     * what port to run the timing exchange on? 123 or other port? 2) Privacy considerations - Need to write down the objective in the draft, which seems to be:     - prevent linkability of client even if the client does not know that its IP address has changed from IPa to IPb. We do not want a *passive* monitor to use info in the NTP/NTS packet to link IPa and IPb. - Some justification in the draft for the use case for which the client does not know that its IP address has changed.      - Daniel to provide some performance numbers to give us an idea of the performance of his protocol as currently written in draft, and also with encryption of the NTP header added. - Decision: Fix legacy client linkability issues in the NTP header, because if we don't fix them, all the mechanisms used to prevent linkability in NTS have little point.  Roughly, the idea is to zero out all identifying fields in the client query that are not used by the server. Aanchal and Daniel to draft this. 2. Way forward for the various NTS documents (see above) - Clarify how Daniel and Kristof can work on the merged documents - Daniel will provide an update to the merged document according the decision above mentioned 3. draft-aanchal4-ntp-mac Aanchal presented an update of the draft-aanchal4-ntp-mac. The new version of the draft recommends the use of CMAC because of a "nonce reuse vulnaribility" of a GMAC (for more details refer to the session's materials section) 4. BCP draft-ietf-ntp-bcp Denis gave an update of the BCP. It is supposed to be ready for WGLC ... 5. Way forward for drafts related to extension fields and refid - draft-stenn-ntp-ipv6-refid-hash - draft-stenn-ntp-leap-smear-refid - draft-stenn-ntp-not-you-refid These three drafs shall be combined and resubmitted as draft-ietf-ntp-refid-updates as possible (Sharon and Harlan) - draft-mayer-ntp-mac-extension-field This draft should go forward - draft-stenn-ntp-last-extension - draft-stenn-ntp-i-do The processing on this document has been postponed to later Jabber archive: https://www.ietf.org/jabber/logs/ntp/2016-10-14.html