idnits 2.17.1 draft-ietf-ntp-roughtime-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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 27, 2020) is 1550 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-ntp-using-nts-for-ntp-20 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: Informational A. Langley 5 Expires: July 30, 2020 Google 6 W. Ladd 7 Cloudflare 8 January 27, 2020 10 Roughtime 11 draft-ietf-ntp-roughtime-00 13 Abstract 15 This document specifies Roughtime - a protocol that aims to achieve 16 rough time synchronization while detecting servers that provide 17 inaccurate time and providing cryptographic proof of their 18 malfeasance. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 30, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 57 4. The guarantee . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1.1. uint32 . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1.2. uint64 . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1.3. Tag . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7 64 5.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.3. The Merkle Tree . . . . . . . . . . . . . . . . . . . . . 9 69 6.3.1. Root value validity check algorithm . . . . . . . . . 10 70 6.4. Validity of response . . . . . . . . . . . . . . . . . . 10 71 7. Integration into ntp . . . . . . . . . . . . . . . . . . . . 10 72 8. Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 11 73 9. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 12 75 11. Trust anchors and policies . . . . . . . . . . . . . . . . . 12 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 13.1. Service Name and Transport Protocol Port Number Registry 13 79 13.2. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 13 80 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 82 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 16.2. Informative References . . . . . . . . . . . . . . . . . 16 85 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 Time synchronization is essential to Internet security as many 91 security protocols and other applications require synchronization 92 [RFC7384] [MCBG]. Unfortunately widely deployed protocols such as 93 the Network Time Protocol (NTP) [RFC5905] lack essential security 94 features, and even newer protocols like Network Time Security (NTS) 95 [I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers 96 behave correctly. Authenticating time servers prevents network 97 adversaries from modifying time packets, but an authenticated time 98 server still has full control over the contents of the time packet 99 and may go rogue. The Roughtime protocol provides cryptographic 100 proof of malfeasance, enabling clients to detect and prove to a third 101 party a server's attempts to influence the time a client computes. 103 +--------------+----------------------+-----------------------------+ 104 | Protocol | Authenticated Server | Server Malfeasance Evidence | 105 +--------------+----------------------+-----------------------------+ 106 | NTP, Chronos | N | N | 107 | NTP-MD5 | Y* | N | 108 | NTP-Autokey | Y** | N | 109 | NTS | Y | N | 110 | Roughtime | Y | Y | 111 +--------------+----------------------+-----------------------------+ 113 Security Properties of current protocols 115 Table 1 117 Y* For security issues with symmetric-key based NTP-MD5 118 authentication, please refer to RFC 8573 [RFC8573]. 120 Y** For security issues with Autokey Public Key Authentication, refer 121 to [Autokey]. 123 More specifically, 125 o If a server's timestamps do not fit into the time context of other 126 servers' responses, then a Roughtime client can cryptographically 127 prove this misbehavior to third parties. This helps detect "bad" 128 servers. 130 o A Roughtime client can roughly detect (with no absolute guarantee) 131 a delay attack [DelayAttacks] but can not cryptographically prove 132 this to a third party. However, the absence of proof of 133 malfeasance should not be considered a proof of absence of 134 malfeasance. So Roughtime should not be used as a witness that a 135 server is overall "good". 137 o Note that delay attacks cannot be detected/stopped by any 138 protocol. Delay attacks can not, however, undermine the security 139 guarantees provided by Roughtime. 141 o Although delay attacks cannot be prevented, they can be limited to 142 a predetermined upper bound. This can be done by defining a 143 maximal tolerable Round Trip Time (RTT) value, MAX-RTT, that a 144 Roughtime client is willing to accept. A Roughtime client can 145 measure the RTT of every request-response handshake and compare it 146 to MAX-RTT. If the RTT exceeds MAX-RTT, the corresponding server 147 is assumed to be a falseticker. When this approach is used the 148 maximal time error that can be caused by a delay attack is MAX- 149 RTT/2. It should be noted that this approach assumes that the 150 nature of the system is known to the client, including reasonable 151 upper bounds on the RTT value. 153 2. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 3. Protocol Overview 163 Roughtime is a protocol for rough time synchronization that enables 164 clients to provide cryptographic proof of server malfeasance. It 165 does so by having responses from servers include a signature with a 166 certificate rooted in a long-term public/private key pair over a 167 value derived from a nonce provided by the client in its request. 168 This provides cryptographic proof that the timestamp was issued after 169 the server received the client's request. The derived value included 170 in the server's response is the root of a Merkle tree which includes 171 the hash of the client's nonce as the value of one of its leaf nodes. 172 This enables the server to amortize the relatively costly signing 173 operation over a number of client requests. 175 Single server mode: At its most basic level, Roughtime is a one round 176 protocol in which a completely fresh client requests the current time 177 and the server sends a signed response. The response includes a 178 timestamp and a radius used to indicate the server's certainty about 179 the reported time. For example, a radius of 1,000,000 microseconds 180 means the server is absolutely confident that the true time is within 181 one second of the reported time. 183 The server proves freshness of its response as follows: The client's 184 request contains a nonce. The server incorporates the nonce into its 185 signed response so that the client can verify the server's signatures 186 covering the nonce issued by the client. Provided that the nonce has 187 sufficient entropy, this proves that the signed response could only 188 have been generated after the nonce. 190 Chaining multiple servers: For subsequent requests, the client 191 generates a new nonce by hashing the reply from the previous server 192 with a random value (a blind). This proves that the nonce was 193 created after the reply from the previous server. It sends the new 194 nonce in a request to the next server and receives a response that 195 includes a signature covering the nonce. 197 Cryptographic proof of misbehavior: If the time from the second 198 server is before the first, then the client has proof that at least 199 one of the servers is misbehaving; the reply from the second server 200 implicitly shows that it was created later because of the way that 201 the client constructed the nonce. If the time from the second server 202 is too far in the future, the client can contact the first server 203 again with a new nonce generated from the second server's response 204 and get a signature that was provably created afterwards, but with an 205 earlier timestamp. 207 With only two servers, the client can end up with proof that 208 something is wrong, but no idea what the correct time is. But with 209 half a dozen or more independent servers, the client will end up with 210 chain of proof of any server's misbehavior, signed by several others, 211 and (presumably) enough accurate replies to establish what the 212 correct time is. Furthermore, this proof may be validated by third 213 parties ultimately leading to a revocation of trust in the 214 misbehaving server. 216 4. The guarantee 218 A Roughtime server guarantees that a response to a query sent at t_1, 219 received at t_2, and with timestamp t_3 has been created between the 220 transmission of the query and its reception. If t_3 is not within 221 that interval, a server inconsistency may be detected and used to 222 impeach the server. The propagation of such a guarantee and its use 223 of type synchronization is discussed in Section 7. No delay attacker 224 may affect this: they may only expand the interval between t_1 and 225 t_2, or of course stop the measurement in the first place. 227 5. Message Format 229 Roughtime messages are maps consisting of one or more (tag, value) 230 pairs. They start with a header, which contains the number of pairs, 231 the tags, and value offsets. The header is followed by a message 232 values section which contains the values associated with the tags in 233 the header. Messages MUST be formatted according to Figure 1 as 234 described in the following sections. 236 Messages may be recursive, i.e. the value of a tag can itself be a 237 Roughtime message. 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Number of pairs (uint32) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 . . 246 . N-1 offsets (uint32) . 247 . . 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 . . 252 . N tags (uint32) . 253 . . 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 . . 258 . Values . 259 . . 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 1: Roughtime Message Format 265 5.1. Data Types 267 5.1.1. uint32 269 A uint32 is a 32 bit unsigned integer. It is serialized with the 270 least significant byte first. 272 5.1.2. uint64 274 A uint64 is a 64 bit unsigned integer. It is serialized with the 275 least significant byte first. 277 5.1.3. Tag 279 Tags are used to identify values in Roughtime packets. A tag is a 280 uint32 but may also be listed as a sequence of up to four ASCII 281 characters [RFC0020]. ASCII strings shorter than four characters can 282 be unambiguously converted to tags by padding them with zero bytes. 283 For example, the ASCII string "NONC" would correspond to the tag 284 0x434e4f4e and "PAD" would correspond to 0x00444150. 286 5.1.4. Timestamp 288 A timestamp is a uint64 interpreted in the following way. The most 289 significant 3 bytes contain the integer part of a Modified Julian 290 Date (MJD). The least significant 5 bytes is a count of the number 291 of Coordinated Universal Time (UTC) microseconds [ITU-R_TF.460-6] 292 since midnight on that day. 294 The MJD is the number of UTC days since 17 November 1858 295 [ITU-R_TF.457-2]. 297 Note that, unlike NTP, this representation does not use the full 298 number of bits in the fractional part and that days with leap seconds 299 will have more or fewer than the nominal 86,400,000,000 microseconds. 301 5.2. Header 303 All Roughtime messages start with a header. The first four bytes of 304 the header is the uint32 number of tags N, and hence of (tag, value) 305 pairs. The following 4*(N-1) bytes are offsets, each a uint32. The 306 last 4*N bytes in the header are tags. 308 Offsets refer to the positions of the values in the message values 309 section. All offsets MUST be multiples of four and placed in 310 increasing order. The first post-header byte is at offset 0. The 311 offset array is considered to have a not explicitly encoded value of 312 0 as its zeroth entry. The value associated with the ith tag begins 313 at offset[i] and ends at offset[i+1]-1, with the exception of the 314 last value which ends at the end of the packet. Values may have zero 315 length. 317 Tags MUST be listed in the same order as the offsets of their values. 318 A tag MUST NOT appear more than once in a header. 320 6. Protocol 322 Roughtime messages are sent between clients and servers as UDP 323 packets, or over TCP. When transporting over TCP, the packets are 324 prefixed with their length as a uint32. Currently no servers exist 325 for the TCP version. As described in Section 3, clients initiate 326 time synchronization by sending request packets containing a nonce to 327 servers who send signed time responses in return. 329 6.1. Requests 331 A request is a Roughtime message with the tag NONC. The size of the 332 request message SHOULD be at least 1024 bytes. To attain this size 333 the PAD tag SHOULD be added to the message. Tags other than NONC 334 SHOULD be ignored by the server. Responding to requests shorter than 335 1024 bytes is OPTIONAL and servers MUST NOT send responses larger 336 than the requests they are replying to. 338 The value of the NONC tag is a 64 byte nonce. It SHOULD be generated 339 by hashing a previous Roughtime response message together with a 340 blind as described in Section 8. If no previous responses are 341 avaiable to the client, the nonce SHOULD be generated at random. 343 The PAD tag SHOULD be used by clients to ensure their request 344 messages are at least 1024 bytes in size. Its value SHOULD be all 345 zeros. 347 6.2. Responses 349 A response contains the tags SREP, SIG, CERT, INDX, and PATH. The 350 SIG tag is a signature over the SREP value using the public key 351 contained in CERT, as explained below. 353 The SREP tag contains a time response. Its value is a Roughtime 354 message with the tags ROOT, MIDP, and RADI. 356 The ROOT tag contains a 32 byte value of a Merkle tree root as 357 described in Section 6.3. 359 The MIDP tag value is a timestamp of the moment of processing. 361 The RADI tag value is a uint32 representing the server's estimate of 362 the accuracy of MIDP in microseconds. Servers MUST ensure that the 363 true time is within (MIDP-RADI, MIDP+RADI) at the time they compose 364 the response packet. 366 The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a 367 signature context concatenated with the entire value of a DELE or 368 SREP tag. Signatures of DELE tags use the ASCII string "RoughTime v1 369 delegation signature--" and signatures of SREP tags use the ASCII 370 string "RoughTime v1 response signature" as signature context. Both 371 strings include a terminating zero byte. 373 The CERT tag contains a public-key certificate signed with the 374 server's long-term key. Its value is a Roughtime message with the 375 tags DELE and SIG, where SIG is a signature over the DELE value. 377 The DELE tag contains a delegated public-key certificate used by the 378 server to sign the SREP tag. Its value is a Roughtime message with 379 the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to 380 enable separation of a long-term public key from keys on devices 381 exposed to the public Internet. 383 The MINT tag is the minimum timestamp for which the key in PUBK is 384 trusted to sign responses. MIDP MUST be more than or equal to MINT 385 for a response to be considered valid. 387 The MAXT tag is the maximum timestamp for which the key in PUBK is 388 trusted to sign responses. MIDP MUST be less than or equal to MAXT 389 for a response to be considered valid. 391 The PUBK tag contains a temporary 32 byte Ed25519 public key which is 392 used to sign the SREP tag. 394 The INDX tag value is a uint32 determining the position of NONC in 395 the Merkle tree used to generate the ROOT value as described in 396 Section 6.3. 398 The PATH tag value is a multiple of 32 bytes long and represents a 399 path of 32 byte hash values in the Merkle tree used to generate the 400 ROOT value as described in Section 6.3. In the case where a response 401 is prepared for a single request and the Merkle tree contains only 402 the root node, the size of PATH is zero. 404 6.3. The Merkle Tree 406 A Merkle tree is a binary tree where the value of each non-leaf node 407 is a hash value derived from its two children. The root of the tree 408 is thus dependent on all leaf nodes. 410 In Roughtime, each leaf node in the Merkle tree represents the nonce 411 of one request that a response message is sent in reply to. Leaf 412 nodes are indexed left to right, beginning with zero. 414 The values of all nodes are calculated from the leaf nodes and up 415 towards the root node using the first 32 bytes of the output of the 416 SHA-512 hash algorithm [RFC6234]. For leaf nodes, the byte 0x00 is 417 prepended to the nonce before applying the hash function. For all 418 other nodes, the byte 0x01 is concatenated with first the left and 419 then the right child node value before applying the hash function. 421 The value of the Merkle tree's root node is included in the ROOT tag 422 of the response. 424 The index of a request's nonce node is included in the INDX tag of 425 the response. 427 The values of all sibling nodes in the path between a request's nonce 428 node and the root node is stored in the PATH tag so that the client 429 can reconstruct and validate the value in the ROOT tag using its 430 nonce. 432 6.3.1. Root value validity check algorithm 434 One starts by computing the hash of the NONC value from the request, 435 with 0x00 prepended. Then one walks from the least significant bit 436 of INDX to the most significant bit, and also walks towards the end 437 of PATH. 439 If PATH ends then the remaining bits of the INDX MUST be all zero. 440 This indicates the termination of the walk, and the current value 441 MUST equal ROOT if the response is valid. 443 If the current bit is 0, one hashes 0x01, the current hash, and the 444 value from PATH to derive the next current value. 446 If the current bit is 1 one hashes 0x01, the value from PATH, and the 447 current hash to derive the next current value. 449 6.4. Validity of response 451 A client MUST check the following properties when it receives a 452 response. We assume the long-term server public key is known to the 453 client through other means. 455 o The signature in CERT was made with the long-term key of the 456 server. 458 o The DELE timestamps and the MIDP value are consistent. 460 o The INDX and PATH values prove NONC was included in the Merkle 461 tree with value ROOT using the algorithm in Section 6.3.1. 463 o The signature of SREP in SIG validates with the public key in 464 DELE. 466 A response that passes these checks is said to be valid. Validity of 467 a response does not prove the time is correct, but merely that the 468 server signed it, and thus guarantees that it began to compute the 469 signature at a time in the interval (MIDP-RADI, MIDP+RADI). 471 7. Integration into ntp 473 We assume that there is a bound PHI on the frequency error in the 474 clock on the machine. Given a measurement taken at a local time t1, 475 we know the true time is in [ t1-delta-sigma, t1-delta+sigma ]. 476 After d seconds have elapsed we know the true time is within [ t1- 477 delta-sigma-d*PHI, t1-delta+sigma+d*PHI]. A simple and effective way 478 to mix with NTP or PTP discipline of the clock is to trim the 479 observed intervals in NTP to fit entirely within this window or 480 reject measurements that fall to far outside. This assumes time has 481 not been stepped. If the NTP process decides to step the time, it 482 MUST use roughtime to ensure the new truetime estimate that will be 483 stepped to is consistent with the true time. 485 Should this window become too large, another roughtime measurement is 486 called for. The definition of "too large" is implementation defined. 488 Implementations MAY use other, more sophisticated means of adjusting 489 the clock respecting roughtime information. 491 8. Cheater Detection 493 A chain of responses is a series of responses where the SHA-512 hash 494 of the preceding response H, is concatenated with a 64 byte blind X, 495 and then SHA-512(H, X) is the nonce used in the subsequent response. 496 These may be represented as an array of objects in JavaScript Object 497 Notation (JSON) format [RFC8259] where each object may have keys 498 "blind" and "response_packet". Packet has the Base64 [RFC4648] 499 encoded bytes of the packet and blind is the Base64 encoded blind 500 used for the next nonce. The last packet needs no blind. 502 A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 > 503 MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j 504 such that i < j, (r_i, r_j) is an invalid pair. 506 Invalidity of a chain is proof that causality has been violated if 507 all servers were reporting correct time. An invalid chain where all 508 individual responses are valid is cryptographic proof of malfeasance 509 of at least one server: if all servers had the correct time in the 510 chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2. 512 In conducting the comparison of timestamps one must know the length 513 of a day and hence have historical leap second data for the days in 514 question. However if violations are greater then a second the loss 515 of leap second data doesn't impede their detection. 517 9. Grease 519 Servers MAY send back a fraction of responses that are syntactically 520 invalid or contain invalid signatures as well as incorrect times. 521 Clients MUST properly reject such responses. Servers MUST NOT send 522 back responses with incorrect times and valid signatures. Either 523 signature MAY be invalid for this application. 525 10. Roughtime Servers 527 The below list contains a list of servers with their public keys in 528 Base64 format. These servers may implement older versions of this 529 specification. 531 address: roughtime.cloudflare.com 532 port: 2002 533 long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo= 535 address: roughtime.int08h.com 536 port: 2002 537 long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= 539 address: roughtime.sandbox.google.com 540 port: 2002 541 long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= 543 address: roughtime.se 544 port: 2002 545 long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= 547 11. Trust anchors and policies 549 A trust anchor is any distributor of a list of trusted servers. It 550 is RECOMMENDED that trust anchors subscribe to a common public forum 551 where evidence of malfeasance may be shared and discussed. Trust 552 anchors SHOULD subscribe to a zero-tolerance policy: any generation 553 of incorrect timestamps will result in removal. To enable this trust 554 anchors SHOULD list a wide variety of servers so the removal of a 555 server does not result in operational issues for clients. Clients 556 SHOULD attempt to detect malfeasance and have a way to report it to 557 trust anchors. 559 Because only a single roughtime server is required for successful 560 synchronization, Roughtime does not have the incentive problems that 561 have prevented effective enforcement of discipline on the web PKI. 562 We expect that some clients will aggressively monitor server 563 behavior. 565 12. Acknowledgements 567 Thomas Peterson corrected multiple nits. Marcus Dansarie, Peter 568 Loethberg (Lothberg), Tal Mizrahi, Ragnar Sundblad, Kristof Teichel, 569 and the other members of the NTP working group contributed comments 570 and suggestions. 572 13. IANA Considerations 574 13.1. Service Name and Transport Protocol Port Number Registry 576 IANA is requested to allocate the following entry in the Service Name 577 and Transport Protocol Port Number Registry [RFC6335]: 579 Service Name: Roughtime 581 Transport Protocol: udp 583 Assignee: IESG 585 Contact: IETF Chair 587 Description: Roughtime time synchronization 589 Reference: [[this memo]] 591 Port Number: [[TBD1]], selected by IANA from the User Port range 593 13.2. Roughtime Tag Registry 595 IANA is requested to create a new registry entitled "Roughtime Tag 596 Registry". Entries SHALL have the following fields: 598 Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. 600 ASCII Representation (OPTIONAL): The ASCII representation of the 601 tag in accordance with Section 5.1.3 of this memo, if applicable. 603 Reference (REQUIRED): A reference to a relevant specification 604 document. 606 The policy for allocation of new entries in this registry SHOULD be: 607 Specification Required. 609 The initial contents of this registry SHALL be as follows: 611 +------------+----------------------+---------------+ 612 | Tag | ASCII Representation | Reference | 613 +------------+----------------------+---------------+ 614 | 0x00444150 | PAD | [[this memo]] | 615 | 0x00474953 | SIG | [[this memo]] | 616 | 0x434e4f48 | NONC | [[this memo]] | 617 | 0x454c4544 | DELE | [[this memo]] | 618 | 0x48544150 | PATH | [[this memo]] | 619 | 0x49444152 | RADI | [[this memo]] | 620 | 0x4b425550 | PUBK | [[this memo]] | 621 | 0x5044494d | MIDP | [[this memo]] | 622 | 0x50455253 | SREP | [[this memo]] | 623 | 0x544e494d | MINT | [[this memo]] | 624 | 0x544f4f52 | ROOT | [[this memo]] | 625 | 0x54524543 | CERT | [[this memo]] | 626 | 0x5458414d | MAXT | [[this memo]] | 627 | 0x58444e49 | INDX | [[this memo]] | 628 +------------+----------------------+---------------+ 630 14. Security Considerations 632 Since the only supported signature scheme, Ed25519, is not quantum 633 resistant, this protocol will not survive the advent of quantum 634 computers. 636 Maintaining a list of trusted servers and adjudicating violations of 637 the rules by servers is not discussed in this document and is 638 essential for security. Roughtime clients MUST update their view of 639 which servers are trustworthy in order to benefit from the detection 640 of misbehavior. 642 Validating timestamps made on different dates requires knowledge of 643 leap seconds in order to calculate time intervals correctly. 645 Servers carry out a significant amount of computation in response to 646 clients, and thus may experience vulnerability to denial of service 647 attacks. 649 This protocol does not provide any confidentiality, and given the 650 nature of timestamps such impact is minor. 652 The compromise of a PUBK's private key, even past MAXT, is a problem 653 as the private key can be used to sign invalid times that are in the 654 range MINT to MAXT, and thus violate the good behavior guarantee of 655 the server. 657 Servers MUST NOT send response packets larger than the request 658 packets sent by clients, in order to prevent amplification attacks. 660 15. Privacy Considerations 662 This protocol is designed to obscure all client identifiers. Servers 663 necessarily have persistent long-term identities essential to 664 enforcing correct behavior. Generating nonces from previous 665 responses without using a blind can enable tracking of clients as 666 they move between networks. 668 16. References 670 16.1. Normative References 672 [ITU-R_TF.457-2] 673 ITU-R, "Use of the Modified Julian Date by the Standard- 674 Frequency and Time-Signal Services", ITU-R 675 Recommendation TF.457-2, October 1997. 677 [ITU-R_TF.460-6] 678 ITU-R, "Standard-Frequency and Time-Signal Emissions", 679 ITU-R Recommendation TF.460-6, February 2002. 681 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 682 RFC 20, DOI 10.17487/RFC0020, October 1969, 683 . 685 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 686 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 687 . 689 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 690 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 691 DOI 10.17487/RFC6234, May 2011, 692 . 694 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 695 Cheshire, "Internet Assigned Numbers Authority (IANA) 696 Procedures for the Management of the Service Name and 697 Transport Protocol Port Number Registry", BCP 165, 698 RFC 6335, DOI 10.17487/RFC6335, August 2011, 699 . 701 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 702 Signature Algorithm (EdDSA)", RFC 8032, 703 DOI 10.17487/RFC8032, January 2017, 704 . 706 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 707 Interchange Format", STD 90, RFC 8259, 708 DOI 10.17487/RFC8259, December 2017, 709 . 711 16.2. Informative References 713 [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", 714 2012, . 716 [DelayAttacks] 717 Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks 718 Against Time Synchronization Protocols", 719 DOI 10.1109/ISPCS.2012.6336612, 2012, 720 . 722 [I-D.ietf-ntp-using-nts-for-ntp] 723 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 724 Sundblad, "Network Time Security for the Network Time 725 Protocol", draft-ietf-ntp-using-nts-for-ntp-20 (work in 726 progress), July 2019. 728 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 729 "Attacking the Network Time Protocol", 2015, 730 . 732 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 733 DOI 10.17487/RFC0768, August 1980, 734 . 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 742 "Network Time Protocol Version 4: Protocol and Algorithms 743 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 744 . 746 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 747 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 748 October 2014, . 750 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 751 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 752 May 2017, . 754 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 755 for the Network Time Protocol", RFC 8573, 756 DOI 10.17487/RFC8573, June 2019, 757 . 759 Appendix A. Terms and Abbreviations 761 ASCII American Standard Code for Information Interchange 763 IANA Internet Assigned Numbers Authority 765 JSON JavaScript Object Notation [RFC8259] 767 MJD Modified Julian Date 769 NTP Network Time Protocol [RFC5905] 771 NTS Network Time Security [I-D.ietf-ntp-using-nts-for-ntp] 773 UDP User Datagram Protocol [RFC0768] 775 UTC Coordinated Universal Time [ITU-R_TF.460-6] 777 Authors' Addresses 779 Aanchal Malhotra 780 Boston University 781 111 Cummington Mall 782 Boston 02215 783 USA 785 Email: aanchal4@bu.edu 787 Adam Langley 788 Google 790 Email: 791 agl@google.com 793 Watson Ladd 794 Cloudflare 795 101 Townsend St 796 San Francisco 797 USA 799 Email: watsonbladd@gmail.com