Minutes interim-2018-ntp-03: Tue 16:30
minutes-interim-2018-ntp-03-201812181630-01

# 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