idnits 2.17.1 draft-aanchal-time-implementation-guidance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Malhotra 3 Internet-Draft Boston University 4 Intended status: Standards Track M. Hoffmann 5 Expires: May 3, 2018 Open Netlabs 6 W. Toorop 7 NLnet Labs 8 October 30, 2017 10 On Implementing Time 11 draft-aanchal-time-implementation-guidance-00 13 Abstract 15 This document describes the properties of different types of time 16 values available on digital systems and provides guidance on choices 17 of these time values to the implementors of applications that use 18 time in some form to provide the basic functionality and security 19 guarantees. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 3, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 The basic functionality and security guarantees claimed by many 56 applications running on digital systems locally or in the Internet 57 hinge on some notion of time. These applications have to choose one 58 of the many types of time values available on the system, each of 59 which has its own specific properties. However, currently these 60 applications seem to be oblivious to the implications of choosing one 61 or the other time value for implementation. This behaviour can be 62 attributed to: a) the lack of clear understanding of the distinct 63 properties of these time values, b) trade-offs of using one or the 64 other for an application, and c) availability and compatibilty of 65 these time values on different operating systems. 67 In this document we describe the properties of various available time 68 values on modern operating systems, discuss the trade-offs of using 69 one over the other, and provide guidance to help implementors make an 70 informed choice with some real-life examples. 72 2. Keeping Time: Different Clocks 74 Because time is relative to an observer, there cannot be a 75 universally agreed upon time. At best we can achieve an 76 approximation by updating our own observed time with a common 77 reference time shared with other observers. 79 As this reference time is what we naively assume clocks on a wall are 80 showing, we shall call it the "wall time." For most applications, it 81 is based on the Universal Coordinated Time (UTC), an international 82 standard time determined by averaging the output of several high- 83 precision time-keeping devices. However, as UTC is following Earth's 84 solar time, it occasionally needs to be adjusted through leap 85 seconds. 87 An individual computer system's preception of time differs from this 88 idealized wall time. Staying close to it requires some effort that 89 comes with its own set of drawbacks. Systems therefore provide 90 access to different types of clocks with different properties. 91 Unfortunately, there is no standard terminology and definitions for 92 these types. For the purpose of this document, we therefore define 93 three different kinds of clocks that a system may or may not provide. 95 2.1. Raw Time 97 At its most fundamental, a system has its own perception of time; its 98 unmodified, "raw time." This time is typically measured by counting 99 cycles of an oscillator. Its quality therefore relies on the 100 stability of this oscillator. 102 As it is a purely subjective time, no general meaning can be attached 103 to any specific value. Only the amount of time passed can be 104 determined by comparing two values. 106 Because raw time is unaltered, it is continuous and strictly 107 monotonically increasing. Its value will always grow at a steady 108 pace, never decrease, never make unexpected jumps, or stip. Such a 109 time is sometimes called a "monotonic time." 111 2.2. Adjusted Raw Time 113 Even if highly accurate oscillators are used, raw time passes at a 114 slightly different rate than wall time. This difference is called 115 clock drift. It depends not only on the quality of the time source 116 but also on environmental factors such as temperature. 118 When this drift is componsated by comparing the passage of raw time 119 to some external time source that is considered to be closer to wall 120 time, the result is "adjusted raw time." This adjustment doesn't 121 happen sporadically but rather, the rate of advance of time is slowed 122 down or sped up slightly until it approaches the reference time 123 again. As a result, adjusted raw time is still monotonic. Like raw 124 time, adjusted raw time is subjective with no specific meaning 125 attached to its values. 127 The most frequently used method of acquiring an external time source 128 is through network timing protocols such as NTP [RFC5905]. As a 129 result, adjusted raw time is susceptible to vulnerabilites of these 130 protocols which may be exploited to maliciously manipulate this time. 132 2.3. Real Time 134 With adjusted raw time, a system already has access to a time that 135 passes at a rate very similar to wall time. By adjusting the time 136 value so that it represents the time passed since an epoch, a well- 137 defined point of wall time such as seconds since midnight January 138 1st, 1970 on Unix systems, time values themselves gather meaning. 139 The result is "real time." 141 While it is often assumed that real time is set to match wall time, 142 this doesn't need to be the case. A system's operator is free to 143 change the value of real time at any time, likewise, system services 144 such as a local NTP client may decide to do so. 146 As a consequence, real time is not monotonic. Not only may it jump 147 forward, its value may even decrease. 149 2.4. Differences from Wall Time 151 These three clock types differ from wall time in three aspects: 153 o Both raw time and adjusted raw time can only represent differences 154 in time by comparing two clock values. Only real time provides 155 absolute time values that can be compared to wall time values. 157 o On the other hand, raw time and adjusted raw time are always 158 monotonic whereas real time may experience sudden changes in value 159 in either direction. 161 o Only adjusted raw time and real time are subject to external 162 adjustments so that time passes at approximately the same rate as 163 wall time. Raw time will over time drift away due to inevitable 164 imperfections of the clock. 166 3. Expressing Time 168 Protocols or applications can express time in one of the two forms, 169 depending on whether global agreement over the point in time is 170 necessary. 172 3.1. Time Stamps 174 A "time stamp" expresses an absolute point in time. In order to 175 reference the same point across multiple systems, it needs to be 176 stated in wall time. 178 Time stamps are often used to express the validity of objects with a 179 limited lifetime that are shared over the network. For instance, 180 PKIX certificates [RFC5280] carry two time stamps expressing their 181 earliest and latest validity. 183 In order to validate a time stamp, a system needs access to a clock 184 that is reasonably close to wall time. 186 3.2. Time Spans 188 In contrast, a "time span" expresses a desired length of time. 189 Examples of time spans are timeout values used in protocols to 190 determine packet loss or Time to Live (TTL) values that govern the 191 lifetime of a local copy of an object. 193 While no access to wall time is necessary for correctly dealing with 194 time spans, using a clock whose time passes at a different rate than 195 wall time will result in different interpretations of time spans by 196 different systems. However, in a network environment, the 197 uncertainty introduced by differing transmission times is likely 198 larger than that introduced by clock drift. 200 4. Current Implementations and Their Flaws 202 Currently, some software takes a common approach towards time stamps 203 and time spans. Time stamps are registered with their wall time 204 value, and time spans are registered with two time stamp values 205 marking the start and the end of the span. Conversion of a time span 206 into those time stamp markers is regularly based on real time. 208 Note that the start of a time span will be the current (real) time in 209 case of a TTL. So, in case something needs to be cached for a 210 certain time, the start time stamp is irrelevant and it is registered 211 together with only the (real) expiration time. 213 Programmers might have had different reasons to base those markings 214 on real time, for example: 216 1. A point in time is intuitively thought of as a wall clock time 217 stamp. Time stamps from outside the software, which the software 218 has to manage are already in wall clock time. The POSIX function 219 to get the current (real) time which is regularly used for this, 220 is gettimeofday(), which comes accross as something providing 221 near wall clock time and which can be used for this purpose. 223 2. Managing time stamps and time span similarly, prevents code 224 complexity. 226 For example, many software is organized around I/O event 227 notification mechanisms like the POSIX select() and poll() system 228 C API functions. These functions wait for a given time span for 229 file descriptors to become ready to perform I/O. The given time 230 span is determined by substracting the current real time value 231 from smallest registered time stamp. When file descriptors are 232 ready, the non-blocking I/O is performed, otherwise the given 233 time span has passed and the action associated with the smallest 234 registered time stamp needs to be performed. 236 For this programming pattern, a sorted list of time stamps has to 237 be maintained by the software. To avoid coding complexity, 238 programmers might prefer a single list for both actual wall clock 239 time stamps and those generated from real time to mark the end of 240 a time span. 242 Using real time as a basis for the time stamps marking the start and 243 end of a time span is bad because of the following reasons. 245 1. It can be set or overwritten manually, 247 2. It is subject to adjustments by timing protocols which on one 248 hand is important to make sure that this time is in sync with the 249 rest of the world but on the other hand makes it dependent on the 250 correctness and security of timing protocols. 252 Recent attacks [SECNTP], [MCBG] show how timing protocols like NTP 253 can be leveraged to shift real time on systems. 255 Time stamps are always based on wall time, so the best one can do is 256 to use real time while dealing with them. However, this limitation 257 does not hold for the time spans. Managing time spans may be 258 implemented in alternative ways which may prove to be more secure and 259 robust. 261 An obvious question to ask is: Why do we need inception and 262 expiration time stamps in the first place to define the validity 263 period of cryptographic objects? Why can't we just use time spans 264 like TTL values instead? The reason is straightforward. 266 The authority determining and setting the validity period on the 267 object can be different from the operator delivering the object. 268 For example the TTL value on DNS resource records indicates to 269 caching DNS resolvers how long to cache those records. These are 270 an operational matter and are thus left to the operators of the 271 DNS zone. 273 The content of the resource records are however determined by the 274 signer of the records. When she is not also the zone operator, 275 she has no way to determine when the records will be queried for, 276 and thus has to depend on cryptographically signed wall clock 277 based time stamps to limit the validity. 279 Note however that DNSSEC signatures do contain the original TTL of 280 a resource record set, restricting the maximum TTL value with 281 which the operator may deliver the resource records. 283 5. Alternative Approaches 285 For time spans, where we only need the rate of passage of time to be 286 close enough to the rest of the world, one should not use the real 287 time to establish the start and end time for the reasons mentioned 288 above. The other two types of time are raw time and adjusted raw 289 time. The important aspect of these monotonic time sources is not 290 their current value but the guarantee that the time source is 291 strictly linearly increasing and thus useful for calculating the 292 difference in time between two samplings. But each comes with its 293 own caveats. 295 Raw time is not subject to any adjustments by timing protocols, 296 i.e., it is not adjusted for the error introduced by clock drift. 297 This could have two repercussions. First, this makes correctness 298 of raw time independent from the errors or security 299 vulnerabilities of the timing protocols. Second, its correctness 300 depends on the clock drift which further depends on various 301 factors such as quality of the oscillator, work load, or ambient 302 temperature on the system and may vary. 304 Adjusted raw time, on the other hand, is subject to adjustments by 305 timing protocols. While it therefore compensates for the errors 306 introduced by the drift of the local clock, this time can be 307 incorrect as it is vulnerable to accuracy and security 308 vulnerabilities of the underlying timing protocol. 310 The choice of time value to be used is application-specific. For 311 instance in applications that can tolerate a certain amount of clock 312 drift [CLOCKDRIFT], implementers can use raw time. However, if that 313 is an issue then one has no choice but to fall back to adjusted raw 314 time. 316 POSIX defines a system C API function which may provide raw time: 317 clock_gettime(), when used with a clock_id of CLOCK_MONOTONIC (when 318 supported by the system). POSIX does not make a distinction between 319 raw time and adjusted raw time in the definition of this function. 320 Beware that with some systems, CLOCK_MONOTONIC deliveres adjusted raw 321 time and that CLOCK_MONOTONIC_RAW needs to be used as clock_id to get 322 unadjusted raw time. Non-POSIX systems may provide different APIs 324 Software employing the pattern organized around I/O event 325 notification mechanisms, as described in Section 4, should maintain 326 two sorted lists of two different types of time stamps: 328 1. One to register events based on time stamps expressed in wall 329 clock time 331 2. One to register the start and end of time spans in (adjusted) raw 332 time 334 To determine the timeout value for a call to select() or poll(), the 335 program needs to get the current time in both real time and in 336 (adjusted) raw time. The current real time is substracted from the 337 lowest value of the time stamps expressed in wall time list. The 338 current (adjusted) raw time from the lowest value of the time stamps 339 expressed in (adjusted) raw time list. The lowest of the values 340 should be used as the timeout value for select() or poll() and 341 determines which action should be performed when te function times 342 out. 344 Alternatively a single list of (adjusted) raw time could be used for 345 both time stamps and time spans. In that case time stamps expressed 346 in wall clock time should be converted into (adjusted) raw time, by 347 first converting it into a time span by substracting real time from 348 it, and then adding the current time in (adjested) raw time. 350 6. Acknowledgements 352 We are thankful to Sharon Goldberg and Benno Overreinder for useful 353 discussions. 355 7. IANA Considerations 357 This memo includes no request to IANA. 359 8. Security Considerations 361 Time is a fundamental component for the security guarantees claimed 362 by various applications. Therefore, any implementor concerned with 363 security should be concerned with how these time values are 364 implemented. This document discusses the security considerations 365 with respect to implementing time values in applications in various 366 sections. 368 9. Informative References 370 [CLOCKDRIFT] 371 Marouani, H. and M. Dagenais, "Internal clock drift 372 estimation in computer clusters", 2008, 373 . 376 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 377 "Attacking the Network Time Protocol", 2015, 378 . 380 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 381 Housley, R., and W. Polk, "Internet X.509 Public Key 382 Infrastructure Certificate and Certificate Revocation List 383 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 384 . 386 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 387 "Network Time Protocol Version 4: Protocol and Algorithms 388 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 389 . 391 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 392 J., and S. Goldberg, "The Security of NTP's Datagram 393 Protocol", 2016, . 395 Authors' Addresses 397 Aanchal Malhotra 398 Boston University 399 111 Cummington Mall 400 Boston 02215 401 USA 403 Email: aanchal4@bu.edu 405 Martin Hoffmann 406 Open Netlabs 407 Science Park 400 408 Amsterdam 1098 XH 409 Netherlands 411 Email: martin@opennetlabs.com 413 Willem Toorop 414 NLnet Labs 415 Science Park 400 416 Amsterdam 1098 XH 417 Netherlands 419 Email: willem@nlnetlabs.nl