idnits 2.17.1 draft-liman-dns-utcstamp-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 (November 20, 2018) is 1983 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 Domain Name Operations L-J. Liman 3 Internet-Draft Netnod 4 Intended status: Informational R. Sundblad 5 Expires: May 24, 2019 Royal Institute of Technology 6 November 20, 2018 8 A UTC Timestamp Option For EDNS 9 draft-liman-dns-utcstamp-00 11 Abstract 13 UTCSTAMP is an EDNS extension to allow a client to request from a 14 server that it includes a timestamp in the response message, and for 15 the server to provide it, if requested and deemed appropriate. This 16 is primarily intended as a debugging tool. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 24, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. General Behavior . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3 57 3.3. Name Server Behavior . . . . . . . . . . . . . . . . . . 3 58 3.4. The UTCSTAMP Option . . . . . . . . . . . . . . . . . . . 4 59 3.5. Presentation Format . . . . . . . . . . . . . . . . . . . 4 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Data Payload . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Presentation format . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. Change History . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. Document Timestamp . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Network security based on encryption depends heavily on the 75 requirement that all involved parties have a common understanding of 76 the time of day. This is true also for the domain name system (DNS) 77 and its transaction signature (TSIG) is no exception. If the time 78 difference between the DNS server and the DNS client is too large, 79 TSIG signatures will not validate. When debugging security-related 80 issues with the DNS, knowing what a remote party believes to be the 81 current time can be very helpful. This documents describes an option 82 to Extended DNS (EDNS) [RFC6891] that allows a client to request that 83 the server includes a timestamp in the response packet, and for the 84 server to provide it, if requested and deemed appropriate. 86 This document is modeled after the NSID option, described in RFC 5001 87 [RFC5001]. 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 3. Protocol 97 This protocol uses an EDNS RFC 6891 [RFC6891] option to signal a 98 resolver's desire for information identifying a server's 99 understanding of the current date and time of day, and to hold the 100 name server's response, if any. 102 3.1. General Behavior 104 The semantics of a UTCSTAMP request are not transitive. That means 105 that any DNS server that receives a incoming query with a UTCSTAMP 106 request, to which it intends to honour it, MUST report its own 107 understanding of the current time, and not relay information obtained 108 from a different host. 110 UTCSTAMP responses MUST NOT be cached. 112 3.2. Resolver Behavior 114 A resolver signals its desire for information about the server's 115 understanding of the current time by sending an empty UTCSTAMP option 116 (Section 3.4) in an EDNS OPT pseudo-RR in the query message. 118 The resolver MUST NOT include any UTCSTAMP payload data in the query 119 message. 121 The resolver MUST NOT expect the server to respond with a valid 122 UTCSTAMP response. 124 The resolver MUST be able to handle the situation that the request is 125 ignored by the server. 127 The resolver SHOULD be able to handle unsolicited UTCSTAMP data sent 128 by the server. 130 3.3. Name Server Behavior 132 A name server that understands the UTCSTAMP option, and chooses to 133 honour a particular UTCSTAMP request, responds by including time 134 information in a UTCSTAMP option (Section 3.4) in an EDNS OPT pseudo- 135 RR in the response message. 137 The name server MUST ignore any UTCSTAMP payload data that might be 138 present in the query message. 140 A name server MUST NOT send a UTCSTAMP option back to a resolver 141 unless it was requested. 143 The UTCSTAMP option is not transitive. In particular, a recursive 144 name server MUST consider UTCSTAMP incoming transactions its client 145 as a separate from its outgoing transactions towards authoritative 146 servers and/or forward resolvers. An incoming UTCSTAMP received from 147 an authoritative (or forward) server MUST NOT be forwarded in an 148 outgoing response to a client. 150 If a server doesn't have an understanding of the current time, it 151 MUST either ignore the request, OR signal the fact that it cannot 152 honour the request by responding with NOTIME data (see Section 3.4). 154 3.4. The UTCSTAMP Option 156 The OPTION-CODE for the UTCSTAMP option is 65394 (provisional and 157 experimental, a permanent one to be assigned by the IANA, should this 158 document be adopted as an RFC.). 160 OPTION-LEN MUST always be zero (0) in UTCSTAMP requests and MUST be 161 at least eight (8) in responses. UTCSTAMP options with OPTION-LENs 162 that deviate from these rules MUST be ignored. 164 The OPTION-DATA section for a UTCSTAMP request must be empty. For 165 responses the UTCSTAMP OPTION-DATA is always an unsigned integer, in 166 network byte order, at least 64-bits long, which represents the 167 number of seconds since 1970-01-01 00:00:00 UTC, with the exception 168 of the value with all bits set (i.e., FFFFFFFFFFFFFFFF (HEX) for a 169 64-bit number) which SHOULD be sent and received as a signal that the 170 server giving out the information understands the request but is 171 incapable of providing the information. The signal is referred to as 172 "NOTIME". If the server understands the request and is able to 173 provide the requested information, but is unwilling to do so 174 (typically due to its configuration), the incoming UTCSTAMP request 175 SHOULD be ignored, and no UTCSTAMP option response given at all. 177 3.5. Presentation Format 179 User interfaces SHOULD present the UTCSTAMP information using human 180 readable ISO 8601 format and UTC time: "YYYY-MM-DD HH:MM:SS UTC" 181 (e.g., "2018-11-15 15:52:23 UTC"). In addition to this, user 182 interfaces MAY also offer to provide the compact ISO 8601 format: 183 "YYYYMMDDTHHMMSSZ" (e.g., "20181115T155223Z"), and/or the pure data 184 from the OPTION-DATA section of the message, in decimal notation 185 (e.g., "1542383543"). 187 The first format is preferred, as UTCSTAMP is intended as a debugging 188 tool for humans, and that version is easier for humans to read. The 189 latter may be useful in automated monitoring scenarios. 191 Software that present this information should examine data carefully, 192 before processing it, and should not assume that the data is neither 193 correct nor sensible. 195 The UTCSTAMP payload is binary data. Any automated comparison 196 between UTCSTAMP payloads SHOULD be a comparison of the raw binary 197 data or the raw data converted to the native byte order for the 198 machine in question. Copy operations MUST NOT assume that the raw 199 UTCSTAMP payload is null-terminated. 201 4. Discussion 203 This section discusses certain aspects of the protocol and explains 204 considerations that led to the chosen design. 206 4.1. Data Payload 208 The choice of "epoch time" (number of seconds since 1970-01-01 209 00:00:00 UTC) was based on simplicity. Epoch time is a simple 210 integer, that will fit in fixed 64-bit container for a long time to 211 come. Epoch time needs no meta information, such as day of week or 212 time zone, and there are no options or alternatives associated with 213 epoch time. By eliminating options and alternatives, there is very 214 little chance of misinterpretation on the recipient side, and since 215 it is a simple number, comparison with other similar timestamps is 216 very straightforward. In certain cases, which are arguably common, 217 it also imposes very little need for computation at the server end. 219 There are of course arguments for making it more complex. An obvious 220 one is that the server may not have, or be able to compute, the 221 specified value. It may have no notion what so ever of a time zone. 222 It may have an internal format that is based on a totally different 223 format than epoch seconds, and may therefore have to perform some 224 computations in order to produce the value. 226 For the former case, time comparison is of more limited value. If 227 the server doesn't even know which time zone it sits in, it has no 228 notion of universal time, and universal time is needed for 229 timestamped signatures to work universally. There may be cases where 230 a limited cluster of servers share a common understanding of time 231 which is not based on time zones, but this protocol is intended to be 232 generic and possible to use on the public global Internet. 234 For the case with a different internal time system, computation will 235 indeed be necessary, but the authors argue that that case is less 236 common, and that the computations are only moderately complex. 238 4.2. Presentation format 240 The presentation format was chosen based on readability and 241 international standards. This protocol is primarily intended to be 242 used by humans when debugging DNS systems. The international 243 standard ISO 8601 specifies different ways to express time and date. 244 The chosen model is a common version of ISO 8601 "extended version", 245 where standardised punctuation is utilised to facilitate readability. 246 It retains the important property that the order of significance is 247 monotonously decreasing. The most significant value (the year) is to 248 the far left, and the least significant value (seconds) is to the far 249 right. This makes it easy for humans to compare two dates. 251 The alternative forms suggested are intended for programmatic use, 252 and may be easier for computers to parse. 254 5. IANA Considerations 256 This memo includes a request to the IANA to assign an EDNS option 257 code for UTCSTAMP. 259 6. Security Considerations 261 This protocol is intended as and aid in debugging scenarios. If this 262 protocol signals that the server's notion of current time differs 263 significantly from that of the client, that is an indicator of a 264 possible problem. If the time given by the server matches that of 265 the client, no knowledge has been gained. 267 This protocol is not intended to be a way to obtain trustworthy time 268 information. There is no guarantee that the server responds with 269 correct data, and the transport of the result is questionable. The 270 transport of data can normally be secured by using TSIG, but as a 271 logical somersault, the primary intent of the protocol is to aid in 272 debugging scenarios where TSIG doesn't work. Therefore TSIG cannot 273 be depended on to provide secure transport. 275 This protocol SHOULD NOT be used to try obtain correct time, as there 276 is no way to ensure that the information is correct. Trusting time 277 obtained with this protocol may lead to complex fault scenarios where 278 incorrect time makes signature validation fail - a situation that can 279 be very difficult to get out without manual intervention - or 280 scenarios where replay attack may succeed. 282 This protocol is primarily intended to be used to compare time 283 between two DNS parties. 285 7. Change History 287 draft-liman-dns-utcstamp-00 289 Initial version. Released 2018-11-20. 291 8. Document Timestamp 293 (This is support for the author. To be removed before publication.) 295 Document Time-stamp: "2018-11-20 16:10:42 liman" 297 9. References 299 9.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, 303 DOI 10.17487/RFC2119, March 1997, 304 . 306 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 307 for DNS (EDNS(0))", STD 75, RFC 6891, 308 DOI 10.17487/RFC6891, April 2013, 309 . 311 9.2. Informative References 313 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", 314 RFC 5001, DOI 10.17487/RFC5001, August 2007, 315 . 317 Authors' Addresses 319 Lars-Johan Liman 320 Netnod 321 Box 30194 322 SE-104 25 Stockholm 323 SE 325 Phone: +46 8 562 860 00 326 Email: liman@netnod.se 327 URI: https://www.netnod.se/ 328 Ragnar Sundblad 329 Royal Institute of Technology 330 SE-100 44 Stockholm 331 SE 333 Phone: +46 8 790 60 00 334 Email: ragge@kth.se 335 URI: https://www.kth.se/