[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                              A. Malhotra
Internet-Draft                                         Boston University
Intended status: Standards Track                             M. Hoffmann
Expires: May 3, 2018                                        Open Netlabs
                                                               W. Toorop
                                                              NLnet Labs
                                                        October 30, 2017


                          On Implementing Time
             draft-aanchal-time-implementation-guidance-00

Abstract

   This document describes the properties of different types of time
   values available on digital systems and provides guidance on choices
   of these time values to the implementors of applications that use
   time in some form to provide the basic functionality and security
   guarantees.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Malhotra, et al.           Expires May 3, 2018                  [Page 1]


Internet-Draft            On Implementing Time              October 2017


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   The basic functionality and security guarantees claimed by many
   applications running on digital systems locally or in the Internet
   hinge on some notion of time.  These applications have to choose one
   of the many types of time values available on the system, each of
   which has its own specific properties.  However, currently these
   applications seem to be oblivious to the implications of choosing one
   or the other time value for implementation.  This behaviour can be
   attributed to: a) the lack of clear understanding of the distinct
   properties of these time values, b) trade-offs of using one or the
   other for an application, and c) availability and compatibilty of
   these time values on different operating systems.

   In this document we describe the properties of various available time
   values on modern operating systems, discuss the trade-offs of using
   one over the other, and provide guidance to help implementors make an
   informed choice with some real-life examples.

2.  Keeping Time: Different Clocks

   Because time is relative to an observer, there cannot be a
   universally agreed upon time.  At best we can achieve an
   approximation by updating our own observed time with a common
   reference time shared with other observers.

   As this reference time is what we naively assume clocks on a wall are
   showing, we shall call it the "wall time."  For most applications, it
   is based on the Universal Coordinated Time (UTC), an international
   standard time determined by averaging the output of several high-
   precision time-keeping devices.  However, as UTC is following Earth's
   solar time, it occasionally needs to be adjusted through leap
   seconds.

   An individual computer system's preception of time differs from this
   idealized wall time.  Staying close to it requires some effort that
   comes with its own set of drawbacks.  Systems therefore provide
   access to different types of clocks with different properties.
   Unfortunately, there is no standard terminology and definitions for
   these types.  For the purpose of this document, we therefore define
   three different kinds of clocks that a system may or may not provide.






Malhotra, et al.           Expires May 3, 2018                  [Page 2]


Internet-Draft            On Implementing Time              October 2017


2.1.  Raw Time

   At its most fundamental, a system has its own perception of time; its
   unmodified, "raw time."  This time is typically measured by counting
   cycles of an oscillator.  Its quality therefore relies on the
   stability of this oscillator.

   As it is a purely subjective time, no general meaning can be attached
   to any specific value.  Only the amount of time passed can be
   determined by comparing two values.

   Because raw time is unaltered, it is continuous and strictly
   monotonically increasing.  Its value will always grow at a steady
   pace, never decrease, never make unexpected jumps, or stip.  Such a
   time is sometimes called a "monotonic time."

2.2.  Adjusted Raw Time

   Even if highly accurate oscillators are used, raw time passes at a
   slightly different rate than wall time.  This difference is called
   clock drift.  It depends not only on the quality of the time source
   but also on environmental factors such as temperature.

   When this drift is componsated by comparing the passage of raw time
   to some external time source that is considered to be closer to wall
   time, the result is "adjusted raw time."  This adjustment doesn't
   happen sporadically but rather, the rate of advance of time is slowed
   down or sped up slightly until it approaches the reference time
   again.  As a result, adjusted raw time is still monotonic.  Like raw
   time, adjusted raw time is subjective with no specific meaning
   attached to its values.

   The most frequently used method of acquiring an external time source
   is through network timing protocols such as NTP [RFC5905].  As a
   result, adjusted raw time is susceptible to vulnerabilites of these
   protocols which may be exploited to maliciously manipulate this time.

2.3.  Real Time

   With adjusted raw time, a system already has access to a time that
   passes at a rate very similar to wall time.  By adjusting the time
   value so that it represents the time passed since an epoch, a well-
   defined point of wall time such as seconds since midnight January
   1st, 1970 on Unix systems, time values themselves gather meaning.
   The result is "real time."

   While it is often assumed that real time is set to match wall time,
   this doesn't need to be the case.  A system's operator is free to



Malhotra, et al.           Expires May 3, 2018                  [Page 3]


Internet-Draft            On Implementing Time              October 2017


   change the value of real time at any time, likewise, system services
   such as a local NTP client may decide to do so.

   As a consequence, real time is not monotonic.  Not only may it jump
   forward, its value may even decrease.

2.4.  Differences from Wall Time

   These three clock types differ from wall time in three aspects:

   o  Both raw time and adjusted raw time can only represent differences
      in time by comparing two clock values.  Only real time provides
      absolute time values that can be compared to wall time values.

   o  On the other hand, raw time and adjusted raw time are always
      monotonic whereas real time may experience sudden changes in value
      in either direction.

   o  Only adjusted raw time and real time are subject to external
      adjustments so that time passes at approximately the same rate as
      wall time.  Raw time will over time drift away due to inevitable
      imperfections of the clock.

3.  Expressing Time

   Protocols or applications can express time in one of the two forms,
   depending on whether global agreement over the point in time is
   necessary.

3.1.  Time Stamps

   A "time stamp" expresses an absolute point in time.  In order to
   reference the same point across multiple systems, it needs to be
   stated in wall time.

   Time stamps are often used to express the validity of objects with a
   limited lifetime that are shared over the network.  For instance,
   PKIX certificates [RFC5280] carry two time stamps expressing their
   earliest and latest validity.

   In order to validate a time stamp, a system needs access to a clock
   that is reasonably close to wall time.

3.2.  Time Spans

   In contrast, a "time span" expresses a desired length of time.
   Examples of time spans are timeout values used in protocols to




Malhotra, et al.           Expires May 3, 2018                  [Page 4]


Internet-Draft            On Implementing Time              October 2017


   determine packet loss or Time to Live (TTL) values that govern the
   lifetime of a local copy of an object.

   While no access to wall time is necessary for correctly dealing with
   time spans, using a clock whose time passes at a different rate than
   wall time will result in different interpretations of time spans by
   different systems.  However, in a network environment, the
   uncertainty introduced by differing transmission times is likely
   larger than that introduced by clock drift.

4.  Current Implementations and Their Flaws

   Currently, some software takes a common approach towards time stamps
   and time spans.  Time stamps are registered with their wall time
   value, and time spans are registered with two time stamp values
   marking the start and the end of the span.  Conversion of a time span
   into those time stamp markers is regularly based on real time.

   Note that the start of a time span will be the current (real) time in
   case of a TTL.  So, in case something needs to be cached for a
   certain time, the start time stamp is irrelevant and it is registered
   together with only the (real) expiration time.

   Programmers might have had different reasons to base those markings
   on real time, for example:

   1.  A point in time is intuitively thought of as a wall clock time
       stamp.  Time stamps from outside the software, which the software
       has to manage are already in wall clock time.  The POSIX function
       to get the current (real) time which is regularly used for this,
       is gettimeofday(), which comes accross as something providing
       near wall clock time and which can be used for this purpose.

   2.  Managing time stamps and time span similarly, prevents code
       complexity.

       For example, many software is organized around I/O event
       notification mechanisms like the POSIX select() and poll() system
       C API functions.  These functions wait for a given time span for
       file descriptors to become ready to perform I/O.  The given time
       span is determined by substracting the current real time value
       from smallest registered time stamp.  When file descriptors are
       ready, the non-blocking I/O is performed, otherwise the given
       time span has passed and the action associated with the smallest
       registered time stamp needs to be performed.

       For this programming pattern, a sorted list of time stamps has to
       be maintained by the software.  To avoid coding complexity,



Malhotra, et al.           Expires May 3, 2018                  [Page 5]


Internet-Draft            On Implementing Time              October 2017


       programmers might prefer a single list for both actual wall clock
       time stamps and those generated from real time to mark the end of
       a time span.

   Using real time as a basis for the time stamps marking the start and
   end of a time span is bad because of the following reasons.

   1.  It can be set or overwritten manually,

   2.  It is subject to adjustments by timing protocols which on one
       hand is important to make sure that this time is in sync with the
       rest of the world but on the other hand makes it dependent on the
       correctness and security of timing protocols.

   Recent attacks [SECNTP], [MCBG] show how timing protocols like NTP
   can be leveraged to shift real time on systems.

   Time stamps are always based on wall time, so the best one can do is
   to use real time while dealing with them.  However, this limitation
   does not hold for the time spans.  Managing time spans may be
   implemented in alternative ways which may prove to be more secure and
   robust.

      An obvious question to ask is: Why do we need inception and
      expiration time stamps in the first place to define the validity
      period of cryptographic objects?  Why can't we just use time spans
      like TTL values instead?  The reason is straightforward.

      The authority determining and setting the validity period on the
      object can be different from the operator delivering the object.
      For example the TTL value on DNS resource records indicates to
      caching DNS resolvers how long to cache those records.  These are
      an operational matter and are thus left to the operators of the
      DNS zone.

      The content of the resource records are however determined by the
      signer of the records.  When she is not also the zone operator,
      she has no way to determine when the records will be queried for,
      and thus has to depend on cryptographically signed wall clock
      based time stamps to limit the validity.

      Note however that DNSSEC signatures do contain the original TTL of
      a resource record set, restricting the maximum TTL value with
      which the operator may deliver the resource records.







Malhotra, et al.           Expires May 3, 2018                  [Page 6]


Internet-Draft            On Implementing Time              October 2017


5.  Alternative Approaches

   For time spans, where we only need the rate of passage of time to be
   close enough to the rest of the world, one should not use the real
   time to establish the start and end time for the reasons mentioned
   above.  The other two types of time are raw time and adjusted raw
   time.  The important aspect of these monotonic time sources is not
   their current value but the guarantee that the time source is
   strictly linearly increasing and thus useful for calculating the
   difference in time between two samplings.  But each comes with its
   own caveats.

      Raw time is not subject to any adjustments by timing protocols,
      i.e., it is not adjusted for the error introduced by clock drift.
      This could have two repercussions.  First, this makes correctness
      of raw time independent from the errors or security
      vulnerabilities of the timing protocols.  Second, its correctness
      depends on the clock drift which further depends on various
      factors such as quality of the oscillator, work load, or ambient
      temperature on the system and may vary.

      Adjusted raw time, on the other hand, is subject to adjustments by
      timing protocols.  While it therefore compensates for the errors
      introduced by the drift of the local clock, this time can be
      incorrect as it is vulnerable to accuracy and security
      vulnerabilities of the underlying timing protocol.

   The choice of time value to be used is application-specific.  For
   instance in applications that can tolerate a certain amount of clock
   drift [CLOCKDRIFT], implementers can use raw time.  However, if that
   is an issue then one has no choice but to fall back to adjusted raw
   time.

   POSIX defines a system C API function which may provide raw time:
   clock_gettime(), when used with a clock_id of CLOCK_MONOTONIC (when
   supported by the system).  POSIX does not make a distinction between
   raw time and adjusted raw time in the definition of this function.
   Beware that with some systems, CLOCK_MONOTONIC deliveres adjusted raw
   time and that CLOCK_MONOTONIC_RAW needs to be used as clock_id to get
   unadjusted raw time.  Non-POSIX systems may provide different APIs

   Software employing the pattern organized around I/O event
   notification mechanisms, as described in Section 4, should maintain
   two sorted lists of two different types of time stamps:

   1.  One to register events based on time stamps expressed in wall
       clock time




Malhotra, et al.           Expires May 3, 2018                  [Page 7]


Internet-Draft            On Implementing Time              October 2017


   2.  One to register the start and end of time spans in (adjusted) raw
       time

   To determine the timeout value for a call to select() or poll(), the
   program needs to get the current time in both real time and in
   (adjusted) raw time.  The current real time is substracted from the
   lowest value of the time stamps expressed in wall time list.  The
   current (adjusted) raw time from the lowest value of the time stamps
   expressed in (adjusted) raw time list.  The lowest of the values
   should be used as the timeout value for select() or poll() and
   determines which action should be performed when te function times
   out.

   Alternatively a single list of (adjusted) raw time could be used for
   both time stamps and time spans.  In that case time stamps expressed
   in wall clock time should be converted into (adjusted) raw time, by
   first converting it into a time span by substracting real time from
   it, and then adding the current time in (adjested) raw time.

6.  Acknowledgements

   We are thankful to Sharon Goldberg and Benno Overreinder for useful
   discussions.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   Time is a fundamental component for the security guarantees claimed
   by various applications.  Therefore, any implementor concerned with
   security should be concerned with how these time values are
   implemented.  This document discusses the security considerations
   with respect to implementing time values in applications in various
   sections.

9.  Informative References

   [CLOCKDRIFT]
              Marouani, H. and M. Dagenais, "Internal clock drift
              estimation in computer clusters", 2008,
              <http://downloads.hindawi.com/journals/
              jcnc/2008/583162.pdf>.

   [MCBG]     Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
              "Attacking the Network Time Protocol", 2015,
              <https://eprint.iacr.org/2015/1020>.



Malhotra, et al.           Expires May 3, 2018                  [Page 8]


Internet-Draft            On Implementing Time              October 2017


   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [SECNTP]   Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner,
              J., and S. Goldberg, "The Security of NTP's Datagram
              Protocol", 2016, <http://eprint.iacr.org/2016/1006>.

Authors' Addresses

   Aanchal Malhotra
   Boston University
   111 Cummington Mall
   Boston  02215
   USA

   Email: aanchal4@bu.edu


   Martin Hoffmann
   Open Netlabs
   Science Park 400
   Amsterdam  1098 XH
   Netherlands

   Email: martin@opennetlabs.com


   Willem Toorop
   NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   Netherlands

   Email: willem@nlnetlabs.nl









Malhotra, et al.           Expires May 3, 2018                  [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/