idnits 2.17.1 draft-roughtime-aanchal-03.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 (July 8, 2019) is 1747 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-19 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: January 9, 2020 Google 6 W. Ladd 7 Cloudflare 8 July 8, 2019 10 Roughtime 11 draft-roughtime-aanchal-03 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 January 9, 2020. 37 Copyright Notice 39 Copyright (c) 2019 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. Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 10 72 8. Grease . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. Roughtime Servers . . . . . . . . . . . . . . . . . . . . . . 11 74 10. Trust anchors and policies . . . . . . . . . . . . . . . . . 12 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 12.1. Service Name and Transport Protocol Port Number Registry 12 78 12.2. Roughtime Tag Registry . . . . . . . . . . . . . . . . . 13 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 15.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 Time synchronization is essential to Internet security as many 90 security protocols and other applications require synchronization 91 [RFC7384] [MCBG]. Unfortunately widely deployed protocols such as 92 the Network Time Protocol (NTP) [RFC5905] lack essential security 93 features, and even newer protocols like Network Time Security (NTS) 94 [I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers 95 behave correctly. Authenticating time servers prevents network 96 adversaries from modifying time packets, but an authenticated time 97 server still has full control over the contents of the time packet 98 and may go rogue. The Roughtime protocol provides cryptographic 99 proof of malfeasance, enabling clients to detect and prove to a third 100 party a server's attempts to influence the time a client computes. 102 +--------------+----------------------+-----------------------------+ 103 | Protocol | Authenticated Server | Server Malfeasance Evidence | 104 +--------------+----------------------+-----------------------------+ 105 | NTP, Chronos | N | N | 106 | NTP-MD5 | Y* | N | 107 | NTP-Autokey | Y** | N | 108 | NTS | Y | N | 109 | Roughtime | Y | Y | 110 +--------------+----------------------+-----------------------------+ 112 Security Properties of current protocols 114 Table 1 116 Y* For security issues with symmetric-key based NTP-MD5 117 authentication, please refer to RFC 8573 [RFC8573]. 119 Y** For security issues with Autokey Public Key Authentication, refer 120 to [Autokey]. 122 More specifically, 124 o If a server's timestamps do not fit into the time context of other 125 servers' responses, then a Roughtime client can cryptographically 126 prove this misbehavior to third parties. This helps detect "bad" 127 servers. 129 o A Roughtime client can roughly detect (with no absolute guarantee) 130 a delay attack [DelayAttacks] but can not cryptographically prove 131 this to a third party. However, the absence of proof of 132 malfeasance should not be considered a proof of absence of 133 malfeasance. So Roughtime should not be used as a witness that a 134 server is overall "good". 136 o Note that delay attacks cannot be detected/stopped by any 137 protocol. Delay attacks can not, however, undermine the security 138 guarantees provided by Roughtime. 140 o Although delay attacks cannot be prevented, they can be limited to 141 a predetermined upper bound. This can be done by defining a 142 maximal tolerable Round Trip Time (RTT) value, MAX-RTT, that a 143 Roughtime client is willing to accept. A Roughtime client can 144 measure the RTT of every request-response handshake and compare it 145 to MAX-RTT. If the RTT exceeds MAX-RTT, the corresponding server 146 is assumed to be a falseticker. When this approach is used the 147 maximal time error that can be caused by a delay attack is MAX- 148 RTT/2. It should be noted that this approach assumes that the 149 nature of the system is known to the client, including reasonable 150 upper bounds on the RTT value. 152 2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. Protocol Overview 162 Roughtime is a protocol for rough time synchronization that enables 163 clients to provide cryptographic proof of server malfeasance. It 164 does so by having responses from servers include a signature with a 165 certificate rooted in a long-term public/private key pair over a 166 value derived from a nonce provided by the client in its request. 167 This provides cryptographic proof that the timestamp was issued after 168 the server received the client's request. The derived value included 169 in the server's response is the root of a Merkle tree which includes 170 the hash of the client's nonce as the value of one of its leaf nodes. 171 This enables the server to amortize the relatively costly signing 172 operation over a number of client requests. 174 Single server mode: At its most basic level, Roughtime is a one round 175 protocol in which a completely fresh client requests the current time 176 and the server sends a signed response. The response includes a 177 timestamp and a radius used to indicate the server's certainty about 178 the reported time. For example, a radius of 1,000,000 microseconds 179 means the server is absolutely confident that the true time is within 180 one second of the reported time. 182 The server proves freshness of its response as follows: The client's 183 request contains a nonce. The server incorporates the nonce into its 184 signed response so that the client can verify the server's signatures 185 covering the nonce issued by the client. Provided that the nonce has 186 sufficient entropy, this proves that the signed response could only 187 have been generated after the nonce. 189 Chaining multiple servers: For subsequent requests, the client 190 generates a new nonce by hashing the reply from the previous server 191 with a random value (a blind). This proves that the nonce was 192 created after the reply from the previous server. It sends the new 193 nonce in a request to the next server and receives a response that 194 includes a signature covering the nonce. 196 Cryptographic proof of misbehavior: If the time from the second 197 server is before the first, then the client has proof that at least 198 one of the servers is misbehaving; the reply from the second server 199 implicitly shows that it was created later because of the way that 200 the client constructed the nonce. If the time from the second server 201 is too far in the future, the client can contact the first server 202 again with a new nonce generated from the second server's response 203 and get a signature that was provably created afterwards, but with an 204 earlier timestamp. 206 With only two servers, the client can end up with proof that 207 something is wrong, but no idea what the correct time is. But with 208 half a dozen or more independent servers, the client will end up with 209 chain of proof of any server's misbehavior, signed by several others, 210 and (presumably) enough accurate replies to establish what the 211 correct time is. Furthermore, this proof may be validated by third 212 parties ultimately leading to a revocation of trust in the 213 misbehaving server. 215 4. The guarantee 217 A Roughtime server guarantees that a response to a query sent at t_1, 218 received at t_2, and with timestamp t_3 has been created between the 219 transmission of the query and its reception. If t_3 is not within 220 that interval, a server inconsistency may be detected and used to 221 impeach the server. The use of such a guarantee in synchronization 222 is currently beyond the grasp of this document. 224 5. Message Format 226 Roughtime messages are maps consisting of one or more (tag, value) 227 pairs. They start with a header, which contains the number of pairs, 228 the tags, and value offsets. The header is followed by a message 229 values section which contains the values associated with the tags in 230 the header. Messages MUST be formatted according to Figure 1 as 231 described in the following sections. 233 Messages may be recursive, i.e. the value of a tag can itself be a 234 Roughtime message. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Number of pairs (uint32) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 . . 243 . N-1 offsets (uint32) . 244 . . 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 . . 249 . N tags (uint32) . 250 . . 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 . . 255 . Values . 256 . . 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 1: Roughtime Message Format 262 5.1. Data Types 264 5.1.1. uint32 266 A uint32 is a 32 bit unsigned integer. It is serialized with the 267 least significant byte first. 269 5.1.2. uint64 271 A uint64 is a 64 bit unsigned integer. It is serialized with the 272 least significant byte first. 274 5.1.3. Tag 276 Tags are used to identify values in Roughtime packets. A tag is a 277 uint32 but may also be listed as a sequence of up to four ASCII 278 characters [RFC0020]. ASCII strings shorter than four characters can 279 be unambiguously converted to tags by padding them with zero bytes. 280 For example, the ASCII string "NONC" would correspond to the tag 281 0x434e4f4e and "PAD" would correspond to 0x00444150. 283 5.1.4. Timestamp 285 A timestamp is a uint64 interpreted in the following way. The most 286 significant 3 bytes contain the integer part of a Modified Julian 287 Date (MJD). The least significant 5 bytes is a count of the number 288 of Coordinated Universal Time (UTC) microseconds [ITU-R_TF.460-6] 289 since midnight on that day. 291 The MJD is the number of UTC days since 17 November 1858 292 [ITU-R_TF.457-2]. 294 Note that, unlike NTP, this representation does not use the full 295 number of bits in the fractional part and that days with leap seconds 296 will have more or fewer than the nominal 86,400,000,000 microseconds. 298 5.2. Header 300 All Roughtime messages start with a header. The first four bytes of 301 the header is the uint32 number of tags N, and hence of (tag, value) 302 pairs. The following 4*(N-1) bytes are offsets, each a uint32. The 303 last 4*N bytes in the header are tags. 305 Offsets refer to the positions of the values in the message values 306 section. All offsets MUST be multiples of four and placed in 307 increasing order. The first post-header byte is at offset 0. The 308 offset array is considered to have a not explicitly encoded value of 309 0 as its zeroth entry. The value associated with the ith tag begins 310 at offset[i] and ends at offset[i+1]-1, with the exception of the 311 last value which ends at the end of the packet. Values may have zero 312 length. 314 Tags MUST be listed in the same order as the offsets of their values. 315 A tag MUST NOT appear more than once in a header. 317 6. Protocol 319 Roughtime messages are sent between clients and servers as UDP 320 packets. As described in Section 3, clients initiate time 321 synchronization by sending request packets containing a nonce to 322 servers who send signed time responses in return. 324 6.1. Requests 326 A request is a Roughtime message with the tag NONC. The size of the 327 request message SHOULD be at least 1024 bytes. To attain this size 328 the PAD tag SHOULD be added to the message. Tags other than NONC 329 SHOULD be ignored by the server. Responding to requests shorter than 330 1024 bytes is OPTIONAL and servers MUST NOT send responses larger 331 than the requests they are replying to. 333 The value of the NONC tag is a 64 byte nonce. It SHOULD be generated 334 by hashing a previous Roughtime response message together with a 335 blind as described in Section 7. If no previous responses are 336 avaiable to the client, the nonce SHOULD be generated at random. 338 The PAD tag SHOULD be used by clients to ensure their request 339 messages are at least 1024 bytes in size. Its value SHOULD be all 340 zeros. 342 6.2. Responses 344 A response contains the tags SREP, SIG, CERT, INDX, and PATH. The 345 SIG tag is a signature over the SREP value using the public key 346 contained in CERT, as explained below. 348 The SREP tag contains a time response. Its value is a Roughtime 349 message with the tags ROOT, MIDP, and RADI. 351 The ROOT tag contains a 32 byte value of a Merkle tree root as 352 described in Section 6.3. 354 The MIDP tag value is a timestamp of the moment of processing. 356 The RADI tag value is a uint32 representing the server's estimate of 357 the accuracy of MIDP in microseconds. Servers MUST ensure that the 358 true time is within (MIDP-RADI, MIDP+RADI) at the time they compose 359 the response packet. 361 The SIG tag value is a 64 byte Ed25519 signature [RFC8032] over a 362 signature context concatenated with the entire value of a DELE or 363 SREP tag. Signatures of DELE tags use the ASCII string "RoughTime v1 364 delegation signature--" and signatures of SREP tags use the ASCII 365 string "RoughTime v1 response signature" as signature context. Both 366 strings include a terminating zero byte. 368 The CERT tag contains a public-key certificate signed with the 369 server's long-term key. Its value is a Roughtime message with the 370 tags DELE and SIG, where SIG is a signature over the DELE value. 372 The DELE tag contains a delegated public-key certificate used by the 373 server to sign the SREP tag. Its value is a Roughtime message with 374 the tags MINT, MAXT, and PUBK. The purpose of the DELE tag is to 375 enable separation of a long-term public key from keys on devices 376 exposed to the public Internet. 378 The MINT tag is the minimum timestamp for which the key in PUBK is 379 trusted to sign responses. MIDP MUST be more than or equal to MINT 380 for a response to be considered valid. 382 The MAXT tag is the maximum timestamp for which the key in PUBK is 383 trusted to sign responses. MIDP MUST be less than or equal to MAXT 384 for a response to be considered valid. 386 The PUBK tag contains a temporary 32 byte Ed25519 public key which is 387 used to sign the SREP tag. 389 The INDX tag value is a uint32 determining the position of NONC in 390 the Merkle tree used to generate the ROOT value as described in 391 Section 6.3. 393 The PATH tag value is a multiple of 32 bytes long and represents a 394 path of 32 byte hash values in the Merkle tree used to generate the 395 ROOT value as described in Section 6.3. In the case where a response 396 is prepared for a single request and the Merkle tree contains only 397 the root node, the size of PATH is zero. 399 6.3. The Merkle Tree 401 A Merkle tree is a binary tree where the value of each non-leaf node 402 is a hash value derived from its two children. The root of the tree 403 is thus dependent on all leaf nodes. 405 In Roughtime, each leaf node in the Merkle tree represents the nonce 406 of one request that a response message is sent in reply to. Leaf 407 nodes are indexed left to right, beginning with zero. 409 The values of all nodes are calculated from the leaf nodes and up 410 towards the root node using the first 32 bytes of the output of the 411 SHA-512 hash algorithm [RFC6234]. For leaf nodes, the byte 0x00 is 412 prepended to the nonce before applying the hash function. For all 413 other nodes, the byte 0x01 is concatenated with first the left and 414 then the right child node value before applying the hash function. 416 The value of the Merkle tree's root node is included in the ROOT tag 417 of the response. 419 The index of a request's nonce node is included in the INDX tag of 420 the response. 422 The values of all sibling nodes in the path between a request's nonce 423 node and the root node is stored in the PATH tag so that the client 424 can reconstruct and validate the value in the ROOT tag using its 425 nonce. 427 6.3.1. Root value validity check algorithm 429 One starts by computing the hash of the NONC value from the request, 430 with 0x00 prepended. Then one walks from the least significant bit 431 of INDX to the most significant bit, and also walks towards the end 432 of PATH. 434 If PATH ends then the remaining bits of the INDX MUST be all zero. 435 This indicates the termination of the walk, and the current value 436 MUST equal ROOT if the response is valid. 438 If the current bit is 0, one hashes 0x01, the current hash, and the 439 value from PATH. 441 If the current bit is 1 one hashes 0x01, the value from PATH, and the 442 current hash. 444 6.4. Validity of response 446 A client MUST check the following properties when it receives a 447 response. We assume the long-term server public key is known to the 448 client through other means. 450 o The signature in CERT was made with the long-term key of the 451 server. 453 o The DELE timestamps and the MIDP value are consistent. 455 o The INDX and PATH values prove NONC was included in the Merkle 456 tree with value ROOT using the algorithm in Section 6.3.1. 458 o The signature of SREP in SIG validates with the public key in 459 DELE. 461 A response that passes these checks is said to be valid. Validity of 462 a response does not prove the time is correct, but merely that the 463 server signed it, and thus guarantees that it began to compute the 464 signature at a time in the interval (MIDP-RADI, MIDP+RADI). 466 7. Cheater Detection 468 A chain of responses is a series of responses where the SHA-512 hash 469 of the preceding response H, is concatenated with a 64 byte blind X, 470 and then SHA-512(H, X) is the nonce used in the subsequent response. 471 These may be represented as an array of objects in JavaScript Object 472 Notation (JSON) format [RFC8259] where each object may have keys 473 "blind" and "response_packet". Packet has the Base64 [RFC4648] 474 encoded bytes of the packet and blind is the Base64 encoded blind 475 used for the next nonce. The last packet needs no blind. 477 A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 > 478 MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j 479 such that i < j, (r_i, r_j) is an invalid pair. 481 Invalidity of a chain is proof that causality has been violated if 482 all servers were reporting correct time. An invalid chain where all 483 individual responses are valid is cryptographic proof of malfeasance 484 of at least one server: if all servers had the correct time in the 485 chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2. 487 In conducting the comparison of timestamps one must know the length 488 of a day and hence have historical leap second data for the days in 489 question. However if violations are greater then a second the loss 490 of leap second data doesn't impede their detection. 492 8. Grease 494 Servers MAY send back a fraction of responses that are syntactically 495 invalid or contain invalid signatures as well as incorrect times. 496 Clients MUST properly reject such responses. Servers MUST NOT send 497 back responses with incorrect times and valid signatures. Either 498 signature MAY be invalid for this application. 500 9. Roughtime Servers 502 The below list contains a list of servers with their public keys in 503 Base64 format. These servers may implement older versions of this 504 specification. 506 address: roughtime.cloudflare.com 507 port: 2002 508 long-term key: gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/S+T7MNTjxo= 510 address: roughtime.int08h.com 511 port: 2002 512 long-term key: AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE= 514 address: roughtime.sandbox.google.com 515 port: 2002 516 long-term key: etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= 518 address: roughtime.se 519 port: 2002 520 long-term key: S3AzfZJ5CjSdkJ21ZJGbxqdYP/SoE8fXKY0+aicsehI= 522 10. Trust anchors and policies 524 A trust anchor is any distributor of a list of trusted servers. It 525 is RECOMMENDED that trust anchors subscribe to a common public forum 526 where evidence of malfeasance may be shared and discussed. Trust 527 anchors SHOULD subscribe to a zero-tolerance policy: any generation 528 of incorrect timestamps will result in removal. To enable this trust 529 anchors SHOULD list a wide variety of servers so the removal of a 530 server does not result in operational issues for clients. Clients 531 SHOULD attempt to detect malfeasance and have a way to report it to 532 trust anchors. 534 Because only a single roughtime server is required for successful 535 synchronization, Roughtime does not have the incentive problems that 536 have prevented effective enforcement of discipline on the web PKI. 537 We expect that some clients will aggressively monitor server 538 behavior. 540 11. Acknowledgements 542 Thomas Peterson corrected multiple nits. Marcus Dansarie, Peter 543 Loethberg (Lothberg), Tal Mizrahi, Ragnar Sundblad, Kristof Teichel, 544 and the other members of the NTP working group contributed comments 545 and suggestions. 547 12. IANA Considerations 549 12.1. Service Name and Transport Protocol Port Number Registry 551 IANA is requested to allocate the following entry in the Service Name 552 and Transport Protocol Port Number Registry [RFC6335]: 554 Service Name: Roughtime 556 Transport Protocol: udp 558 Assignee: IESG 560 Contact: IETF Chair 562 Description: Roughtime time synchronization 564 Reference: [[this memo]] 566 Port Number: [[TBD1]], selected by IANA from the User Port range 568 12.2. Roughtime Tag Registry 570 IANA is requested to create a new registry entitled "Roughtime Tag 571 Registry". Entries SHALL have the following fields: 573 Tag (REQUIRED): A 32-bit unsigned integer in hexadecimal format. 575 ASCII Representation (OPTIONAL): The ASCII representation of the 576 tag in accordance with Section 5.1.3 of this memo, if applicable. 578 Reference (REQUIRED): A reference to a relevant specification 579 document. 581 The policy for allocation of new entries in this registry SHOULD be: 582 Specification Required. 584 The initial contents of this registry SHALL be as follows: 586 +------------+----------------------+---------------+ 587 | Tag | ASCII Representation | Reference | 588 +------------+----------------------+---------------+ 589 | 0x00444150 | PAD | [[this memo]] | 590 | 0x00474953 | SIG | [[this memo]] | 591 | 0x434e4f48 | NONC | [[this memo]] | 592 | 0x454c4544 | DELE | [[this memo]] | 593 | 0x48544150 | PATH | [[this memo]] | 594 | 0x49444152 | RADI | [[this memo]] | 595 | 0x4b425550 | PUBK | [[this memo]] | 596 | 0x5044494d | MIDP | [[this memo]] | 597 | 0x50455253 | SREP | [[this memo]] | 598 | 0x544e494d | MINT | [[this memo]] | 599 | 0x544f4f52 | ROOT | [[this memo]] | 600 | 0x54524543 | CERT | [[this memo]] | 601 | 0x5458414d | MAXT | [[this memo]] | 602 | 0x58444e49 | INDX | [[this memo]] | 603 +------------+----------------------+---------------+ 605 13. Security Considerations 607 Since the only supported signature scheme, Ed25519, is not quantum 608 resistant, this protocol will not survive the advent of quantum 609 computers. 611 Maintaining a list of trusted servers and adjudicating violations of 612 the rules by servers is not discussed in this document and is 613 essential for security. Roughtime clients MUST update their view of 614 which servers are trustworthy in order to benefit from the detection 615 of misbehavior. 617 Validating timestamps made on different dates requires knowledge of 618 leap seconds in order to calculate time intervals correctly. 620 Servers carry out a significant amount of computation in response to 621 clients, and thus may experience vulnerability to denial of service 622 attacks. 624 This protocol does not provide any confidentiality, and given the 625 nature of timestamps such impact is minor. 627 The compromise of a PUBK's private key, even past MAXT, is a problem 628 as the private key can be used to sign invalid times that are in the 629 range MINT to MAXT, and thus violate the good behavior guarantee of 630 the server. 632 Servers MUST NOT send response packets larger than the request 633 packets sent by clients, in order to prevent amplification attacks. 635 14. Privacy Considerations 637 This protocol is designed to obscure all client identifiers. Servers 638 necessarily have persistent long-term identities essential to 639 enforcing correct behavior. Generating nonces from previous 640 responses without using a blind can enable tracking of clients as 641 they move between networks. 643 15. References 645 15.1. Normative References 647 [ITU-R_TF.457-2] 648 ITU-R, "Use of the Modified Julian Date by the Standard- 649 Frequency and Time-Signal Services", ITU-R 650 Recommendation TF.457-2, October 1997. 652 [ITU-R_TF.460-6] 653 ITU-R, "Standard-Frequency and Time-Signal Emissions", 654 ITU-R Recommendation TF.460-6, February 2002. 656 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 657 RFC 20, DOI 10.17487/RFC0020, October 1969, 658 . 660 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 661 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 662 . 664 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 665 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 666 DOI 10.17487/RFC6234, May 2011, 667 . 669 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 670 Cheshire, "Internet Assigned Numbers Authority (IANA) 671 Procedures for the Management of the Service Name and 672 Transport Protocol Port Number Registry", BCP 165, 673 RFC 6335, DOI 10.17487/RFC6335, August 2011, 674 . 676 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 677 Signature Algorithm (EdDSA)", RFC 8032, 678 DOI 10.17487/RFC8032, January 2017, 679 . 681 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 682 Interchange Format", STD 90, RFC 8259, 683 DOI 10.17487/RFC8259, December 2017, 684 . 686 15.2. Informative References 688 [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", 689 2012, . 691 [DelayAttacks] 692 Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks 693 Against Time Synchronization Protocols", 694 DOI 10.1109/ISPCS.2012.6336612, 2012, 695 . 697 [I-D.ietf-ntp-using-nts-for-ntp] 698 Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 699 Sundblad, "Network Time Security for the Network Time 700 Protocol", draft-ietf-ntp-using-nts-for-ntp-19 (work in 701 progress), April 2019. 703 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 704 "Attacking the Network Time Protocol", 2015, 705 . 707 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 708 DOI 10.17487/RFC0768, August 1980, 709 . 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, 713 DOI 10.17487/RFC2119, March 1997, 714 . 716 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 717 "Network Time Protocol Version 4: Protocol and Algorithms 718 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 719 . 721 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 722 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 723 October 2014, . 725 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 726 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 727 May 2017, . 729 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 730 for the Network Time Protocol", RFC 8573, 731 DOI 10.17487/RFC8573, June 2019, 732 . 734 Appendix A. Terms and Abbreviations 736 ASCII American Standard Code for Information Interchange 738 IANA Internet Assigned Numbers Authority 740 JSON JavaScript Object Notation [RFC8259] 742 MJD Modified Julian Date 744 NTP Network Time Protocol [RFC5905] 746 NTS Network Time Security [I-D.ietf-ntp-using-nts-for-ntp] 748 UDP User Datagram Protocol [RFC0768] 750 UTC Coordinated Universal Time [ITU-R_TF.460-6] 752 Authors' Addresses 753 Aanchal Malhotra 754 Boston University 755 111 Cummington Mall 756 Boston 02215 757 USA 759 Email: aanchal4@bu.edu 761 Adam Langley 762 Google 764 Watson Ladd 765 Cloudflare 766 101 Townsend St 767 San Francisco 768 USA 770 Email: watson@cloudflare.com