[Ntp] Minutes from NTP Interim Meeting 2018-12-18

[Dieter Sibold <[e-mail]>]

Dear all,

please find below the minutes from the last NTP interim meeting.

URL: https://datatracker.ietf.org/doc/minutes-interim-2018-ntp-03-201812181630/





-------------------------

# 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

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