Minutes interim-2018-ntp-03: Tue 16:30
Network Time Protocol
||Minutes interim-2018-ntp-03: Tue 16:30
# NTP Virtual Interim Meeting
Time: Dec 18, 2018 4:30 PM UTC
Dieter, Karen, Daniel, Marcus, Martin, Tal, Miroslav, Denis, Kristof, Danny,
Watson Ladd, Rich Salz, Aanchal, Harlan
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
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
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
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
- 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
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
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
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
- 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
- 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
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
immediate handshake which is preventing from accidental DoS attacks.
- Karen: This should be solved by Marcus, Rich, Daniel, Watson, and
- Karen: What about Heiko's request about the TCP and UDP assignment
- Dieter: Meinberg plans to implement NTS as a daemon separated from
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
followed by a discussion. Concerns about NTP rulesets in firewalls,
- All: General consensus that the NTS document shall require a port
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
help that it describes the remaining issues properly
- Sam Weiler propose that we follow Harlan's suggested values for the
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
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
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
use of the mailing list to plan for the hackathon event
- Watson: We might be able to get a public server for interoperability purposes
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
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
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
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
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)
- this document is in WGLC
- no update since Sep. 2018
- 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
but without specifying the circumstances. That needs some elaboration.
- Harlan: Miroslav already pointed out that zero timestamp is problematic, poll
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
neither described nor published
- Karen: ask Aanchal to review all comments regarding this draft and to send a
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
section of NTS but I don't see that it is required to be implemented
- Daniel: It isn't required. But it is still a reference we are not willing to
NTS cannot be published until data minimization is published.
- Danny: A dumb client will ignore any auxiliary information from the server.
clients it doesn't matter what you put into this document.
- Miroslav: If a client supports the adjustment of the poll interval around a
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
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
of any case where you don't want to minimize.
- Daniel, Watson, Harlan, Danny: some discussion about the necessity whether or
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
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
- Karen ask Aanchal to summarize the results thus far
- Karen points out that we might add some generic language to the draft. But
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
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
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
- IERS is responsible for the announcement of leap second
- The national metrology institutes are responsible for dissemination of this
- The BCP contains three different links to this file
- the file is on the IETF website because this file is also included in the
database maintained by IANA (BCP 175)
- Karen: One of the NTP implementors was saying that their code points to the
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
- Denis: Recommend to maintain the link to the TZ database. There is already a
how it is maintained.
- Harlan: the ntpd distribution is using the link to the IETF website. But it
- Daniel: nothing in RFC 5905 presumes the existence of this file in any
- 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.
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
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
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