idnits 2.17.1 draft-mglt-homenet-dnssec-validator-dhc-options-02.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 1 instance 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 (October 21, 2013) is 3840 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-17) exists of draft-ietf-dhc-option-guidelines-14 == Outdated reference: A later version (-16) exists of draft-jabley-dnssec-trust-anchor-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HOMENET D. Migault (Ed) 3 Internet-Draft Orange 4 Intended status: Standards Track October 21, 2013 5 Expires: April 24, 2014 7 DNSSEC Validators DHCP Options 8 draft-mglt-homenet-dnssec-validator-dhc-options-02.txt 10 Abstract 12 DNSSEC provides data integrity and authentication for DNSSEC 13 validators. However, without valid trust anchor(s) and an acceptable 14 value for the current time, DNSSEC validation cannot be performed. 15 As a result, there are multiple cases where DNSSEC validation MUST 16 NOT be performed. In addition, this list of exceptions is expected 17 to become larger over time. 19 Considering an increasing number of cases where DNSSEC is disabled 20 adds complexity to the DNSSEC validator implementations and increases 21 the vectors that disable security. 23 This document assumes that DNSSEC adoption by end devices requires 24 that end devices MUST be able to support a DNSSEC validation always 25 set. This MUST be valid today as well as in the future. 27 This document describes DHCP Options to provision the DHCP Client 28 with valid trust anchors and time so DNSSEC validation can be 29 performed. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 24, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Motivations for providing DNSSEC Trust Anchor . . . . . . 3 68 3.2. Motivations for providing Time . . . . . . . . . . . . . 5 69 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. DHCP DNSSEC Trust Anchor Options . . . . . . . . . . . . . . 6 71 5.1. DHCP DNSSEC KSK RR Trust Anchor Options . . . . . . . . . 6 72 5.2. DHCP DNSSEC KSK CERT Trust Anchor Options . . . . . . . . 6 73 6. DHCP Time Option . . . . . . . . . . . . . . . . . . . . . . 7 74 7. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . 8 75 8. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 9 76 9. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 10 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 10 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 13.2. Informational References . . . . . . . . . . . . . . . . 11 83 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 12 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 DNSSEC [RFC4033], [RFC4034], [RFC4035] adds data authentication and 95 integrity checks to DNS [RFC1034], [RFC1035]. For signature 96 validation, DNSSEC requires a trust anchor such as the Key Signing 97 Key (KSK) of the Root Zone or any other zone. Without a trust 98 anchor, DNSSEC validation cannot be performed. In addition KSKs and 99 signatures are valid for a given period of time. As a result, DNSSEC 100 validation cannot be performed if time shifting is to large. 102 This document considers DHCP DNSSEC Trust Anchor Option and DHCP Time 103 Option to provision a device with trusted KSKs and current time. 104 Although our priority is to provide the Root Zone KSK, we also 105 consider the case other trusted KSK MAY be provided, for example, if 106 a Zone does not provide secure delegation, or to mitigate badly 107 configured DNSSEC zones (like TLDs zones). 109 The main motivation for these DHCP Options is that DHCP enabled 110 devices have DNSSEC validation always set and do not need to perform 111 DNS resolution without DNSSEC validation. In fact, enabling DNS with 112 no validation represents a potential way to remove security and MAY 113 be used by attackers. Similarly, DNSSEC configuration implemented in 114 the end users device, MAY not consider future cases and MAY introduce 115 vulnerabilities. DHCP Options prevent this as long as the 116 relationship between DHCP Client and DHCP Server is trusted. 118 This document assumes that the channel between the DHCP Client and 119 the DHCP Server is trusted and secured with DHCP mechanisms described 120 in [RFC3315], or IPsec [RFC4301]. 122 3. Threat Model 124 This document addresses the case of a device configured with DNSSEC 125 validation set that is plugged in, gets connectivity (using DHCP for 126 example), but fails DNSSEC resolutions because its trust anchor KSK 127 is not valid anymore or its local time is not valid. 129 This threat mainly addresses devices that can be switched off for a 130 long period of time or devices that MAY be off-shelves for a long 131 time before being plugged in. CPEs as well as any homenet devices 132 are concerned by this use case. 134 This threat also addresses DNSSEC emergency key roll over operations. 135 Devices that have cached the out-of-date KSK will not be able to 136 check the signatures until the TTL has expired on all caches. 138 This document proposes DHCP Options that provide the necessary 139 parameters to perform DNSSEC validation. These Options MUST be used 140 on a trusted network over a trusted channel between the DHCP Client 141 and the DHCP Server. These options MAY be used in conjunction of 142 additional mechanisms. 144 3.1. Motivations for providing DNSSEC Trust Anchor 145 The first motivation for providing trusted KSKs is to provide 146 automatic configuration of devices to enable DNSSEC validation. This 147 avoids validator initial KSK provisioning issue as well as KSK roll 148 over issues. 150 A validator MAY not be able to perform signature check with an 151 authenticated KSK because: 153 - 1) It does not have a trust anchor (like the Root Zone KSK) 155 - 2) The KSK MAY have been authenticated, stored or cached with an 156 expiration date valid but is not valid anymore. This MAY 157 happen in the case of an emergency key roll over, if the device 158 has been offline during the key roll over, or if the key roll 159 over is not performed as described in [DPS-KSK], [RFC5011]. 161 - 3) The chain of trust MAY have been broken. This can happen to 162 non Root Zone KSK only and MAY not involve the responsibility 163 of the owner of the zone. The deeper the Zone is in the 164 hierarchy, the more likely this happens. 166 - 4) A DNSSEC zone MAY have been badly signed or a KSK MAY have been 167 badly generated. The DNSSEC MAY be correct, but DNSSEC 168 validator MAY keep for a long time the badly generated KSK, 169 ZSK... 171 The goal of the DHCP DNSSEC Trust Anchor Option is to provide these 172 validators trusted anchors like the Root Zone KSK, as well as other 173 KSKs (TLDs...) so the validator has the proper KSKs to perform DNSSEC 174 validation. 176 Most documents are currently focused on the Root Zone KSK for which 177 recommendations and alternative mechanisms have been described. [I-D 178 .jabley-dnsop-validator-bootstrap] provides guide lines on how to 179 retrieve and select DNSSEC Trust Anchors. Section 5.3 and [I-D 180 .jabley-dnssec-trust-anchor] describes mechanisms to retrieve 181 securely the Root Zone KSK relying on TLS security. It suggests to 182 use insecure DNS resolution to set HTTPS connections. Using HTTPS 183 requires downloading the keyDigest id (key-label) from https:// 184 data.iana.org/root-anchors/root-anchors.xml, followed by an HTTPS 185 request at https://data.iana.org/root-anchors/key-label.crt to get 186 the whole certificate. 188 The key advantages of the DHCP DNSSEC Trust Anchor Option described 189 in this document are that we extend the mechanism to any KSK, and 190 validators can set DNSSEC validation for all DNS queries. However, 191 we do not see any contradiction between recommendations provided by 192 [I-D.jabley-dnsop-validator-bootstrap] and [I-D.jabley-dnssec-trust- 193 anchor] and believe the principle described in these documents SHOULD 194 be applied by the validators. Note also that DHCP DNSSEC Trust 195 Anchor Option only benefits to validators that are configured via 196 DHCP. 198 To recover from a DNSSEC failure and remove a particular data from 199 cache, [I-D.jabley-dnsop-dns-flush] suggests to use a NOTIFY message 200 between Authoritative Servers and Resolvers. This mechanism is set 201 between Recursive Server and Authoritative Servers with a specific 202 trusted relationship. This is probably a selection of TLDs. This 203 document, does not address the DNSSEC failure over Recursive Servers, 204 but addresses more specifically DHCP configured devices. These are 205 typically CPEs or End Users. We believe that configuring and 206 restarting DNSSEC validators with DHCP Option, is an easier way to 207 cope with this issue. First the trust relation between DHCP Server 208 already exists, we do not need additional trusted channel between 209 Authoritative Servers or eventually the Recursive Servers. Then 210 basic implementations of stub resolvers, in CPE or desktops may not 211 address NOTIFY message. 213 3.2. Motivations for providing Time 215 KSKs and signatures are always associated to an expiration time. As 216 a result, DNSSEC validation requires that the validator knows the 217 current time. 219 A number of mechanisms exists like [TLSDATE] or [RFC5905] for setting 220 the time of the device. In addition, [RFC5908] provides a Network 221 Time Protocol (NTP) Server Option for DHCP. The DHCP Time Option 222 described in this document differs from [RFC5908] as it provides an 223 estimation of the current time, instead of providing the NTP servers 224 location information. The time value provided by the DHCP Time 225 Option should be used only if previously mentioned mechanisms are 226 either not implemented on the device or are unavailable. One of the 227 reason MAY be that you MAY need valid DNS(SEC) resolution to use 228 these protocols. The time provided by the DHCP Time Option does not 229 have the accuracy of NTP and SHOULD be considered as a best effort 230 value. [I-D.jabley-dnsop-validator-bootstrap] also recommends that 231 when time has not been verified by the validator, the signature 232 validation SHOULD be done with time off. 234 The key advantage of the DHCP Time Option is that it makes possible 235 to have DNSSEC validation always set. It limits the possible DNSSEC 236 validation variants which potentially expose the device to disable 237 DNSSEC validations. Note also that DHCP Time Option only benefits to 238 validators that are configured via DHCP. 240 4. Terminology 241 5. DHCP DNSSEC Trust Anchor Options 243 This section describes two options: 245 - DHCP DNSSEC KSK Trust Anchor Options: carries the KSK RRset as 246 described in [RFC1035] with a DNSKEY RDATA as described in 247 [RFC4033]. This data is not integrity protected, nor it can be 248 authenticated. Such data SHOULD be trusted over a trusted DHCP 249 channel. 251 - DHCP DNSSEC CERT Trust Anchor Options: Carries a certificate 252 encoded as described in [RFC4398]. The advantage of the 253 Certificate is that is enables authentication of the received 254 information by a trusted party. For example, CPE providers MAY 255 provide a trusted certification authority. Unlike DNSSEC key 256 roll over, the CPE provider controls the key roll over of the 257 certification authority it provides. 259 5.1. DHCP DNSSEC KSK RR Trust Anchor Options 261 The DHCP DNSSEC KSK Trust Anchor Option provides the RRset as 262 mentioned in the DNS(SEC) Zone. In other words, it carries the RR as 263 defined in Section 3.2. of [RFC1035] and a RDATA DNSKEY as defined 264 in Section 2.1 of [RFC4033]. As the RR has a variable length, the 265 DHCP DNSSEC KSK Trust Anchor Options follows the recommendation 266 format of Section 5.9 of [I-D.ietf-dhc-option-guidelines]. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | option-code | option-len | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 . . 274 . KSK RR . 275 . . 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 1: DHCP DNSSEC KSK Trust Anchor Options 279 Payload Description 281 - option-code: OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR 283 - option-len: An unsigned integer giving the length of the KSK RR 284 field in this option in octets 286 5.2. DHCP DNSSEC KSK CERT Trust Anchor Options 287 The DHCP DNSSEC CERT Trust Anchor Option provides a certificate. The 288 CERT RR is described in [RFC4398]. Note that only the RDATA 289 associated to the CERT is present in the DHCP Option. As the RR has 290 a variable length, the DHCP DNSSEC KSK CERT Trust Anchor Options 291 follows the recommendation format of Section 5.9 of [I-D.ietf-dhc- 292 option-guidelines]. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | option-code | option-len | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 . . 300 . KSK CERT RDATA . 301 . . 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 2: DHCP DNSSEC CERT Trust Anchor Options 305 Payload Description 307 - option-code: OPTION_DNSSEC_CERT_TRUST_ANCHOR 309 - option-len: An unsigned integer giving the length of the KSK RR 310 field in this option in octets 312 The X.509 [RFC5280] certificate MUST have a keyUsage set to 313 digitalSignature (0) and nonRepudiation (1). Subject Alternative 314 Name DNS name indicates the name of the zone. 316 In order to be compliant with the certificate of the Root Zone 317 described [I-D.jabley-dnssec-trust-anchor]. The CERT for a KSK 318 SHOULD have a Common Name (CN) with the string "'Zone-FQDN' Zone KSK" 319 followed by the time and date of key generation in the format 320 specified in [RFC3339]. 'Zone-FQDN' is the name of the zone and 321 SHOULD be the same as the one mentioned in Subject Alternative Name. 322 The resourceRecord Attribute SHOULD be set with the DS RRset. 324 6. DHCP Time Option 326 The DHCP DNSSEC Time Option is used by the DHCP Server to indicate 327 the Time to the DHCP Client. The Time is provided in a string format 328 as specified in [RFC3339] and in [I-D.ietf-dhc-option-guidelines] 329 Section 5.8. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | option-code | option-len | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 . . 337 . TXT Time Format . 338 . . 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 2: DHCP Time Options 342 Payload Description 344 - option-code: OPTION_TIME 346 - option-len: A string representing the Time 348 7. DHCP Client Behavior 350 DHCP DNSSEC KSK Trust Anchor Option, DHCP DNSSEC CERT Trust Anchor 351 Option or DHCP Time Option described in this document are intended 352 for DNSSEC validation. If a connected device is not performing 353 DNSSEC validation, it MUST NOT send a DHCP an Option Request DHCP 354 Option (ORO) [RFC3315] for any of these options, and MUST ignore all 355 these options if provided by the DHCP Server. 357 The DHCP sends a DHCP ORO for one or multiple options described in 358 the document. Motivations for sending this Option Request DHCP 359 Option is out of scope of the document. It could be a device 360 switched off for a long time, a device that cannot validate the 361 DNSSEC responses. 363 A channel is considered trusted if 1) the DHCP Server is trusted and 364 authenticated and 2) exchanged data between the DHCP Client and the 365 DHCP Server is integrity protected. IPsec [RFC4301], for example, 366 MAY be used to establish a secure channel. 368 Over a trusted channel, the DHCP Client that performs DNSSEC 369 validation MAY send an ORO for any of the DHCP DNSSEC KSK Trust 370 Anchor Option, the DHCP DNSSEC CERT Trust Anchor Option or the DHCP 371 Time Option to a DHCP Server. 373 Over a trusted channel, the DHCP Client that performs DNSSEC 374 validation SHOULD consider the DHCP DNSSEC KSK Trust Anchor Option, 375 the DHCP DNSSEC CERT Trust Anchor Option or the DHCP Time Option sent 376 by the DHCP Server. 378 Over a non trusted channel, the DHCP Client MAY only send ORO for a 379 DHCP DNSSEC CERT Trust Anchor Option. This option is the only one 380 that MAY be considered by the DHCP Client if sent by the DHCP Server. 381 If the DHCP Client does not trust the signer of the certificate, the 382 option MUST be ignored. 384 When a DHCP DNSSEC KSK Trust Anchor Option or a DHCP DNSSEC CERT 385 Trust Anchor Option is accepted by the DHCP Client, it MUST remove 386 overwrite old values for the KSK with the new one. 388 When a DHCP Time Option is accepted by the DHCP Client, it MUST check 389 the difference between its clock and the time provided by the Option. 390 It SHOULD overwrite its clock value only if the difference is too 391 large. 393 In any other case, ORO requests MUST NOT be sent by the DHCP Client, 394 and options received by the DHCP Server MUST NOT be considered by the 395 DHCP Client. The remaining of the section details when the options 396 MUST NOT be requested by the DHCP Client and MUST be ignored by the 397 DHCP Client when received by the DHCP Server. 399 The DHCP Client MUST NOT send an ORO for a DHCP DNSSEC KSK Trust 400 Anchor Option, a DHCP DNSSEC CERT Trust Anchor Option or a DHCP Time 401 Option to a DHCP Server that is either not trusted or not 402 authenticated. 404 All DHCP DNSSEC KSK Trust Anchor Option, a DHCP DNSSEC CERT Trust 405 Anchor Option or a DHCP Time Option received from DHCP Server that is 406 not authenticated or that is not trusted MUST be ignored by the DHCP 407 Client. 409 The DHCP Client MUST NOT send an ORO for a DHCP DNSSEC KSK Trust 410 Anchor Option or a DHCP Time Option to a trusted DHCP Server over an 411 untrusted channel. A DHCP DNSSEC CERT Trust Anchor Option MAY be 412 requested over an untrusted channel since the certificate is signed 413 and thus can be authenticated. A DHCP DNSSEC CERT Trust Anchor 414 Option signed by an untrusted authority MUST be ignored by the DHCP 415 Client. 417 All DHCP DNSSEC KSK Trust Anchor Option or a DHCP Time Option 418 received from DHCP Server over a channel that is not trusted MUST be 419 ignored by the DHCP Client. 421 8. DHCP Server Behavior 423 The DHCP Server SHOULD properly answer with the requested options in 424 the ORO, even if the DHCP Server does not consider the channel with 425 DHCP Client as trusted. 427 The DHCP Server MAY also provide DHCP DNSSEC KSK Trust Anchor Option, 428 DHCP DNSSEC CERT Trust Anchor Option or DHCP Time Option without 429 being requested by the DHCP Client. This could for example prevent 430 failures not detected by the DHCP Client. 432 9. DHCP Relay Agent Behavior 434 The DHCP Options described in the document do not impact the Relay 435 Agent. 437 10. IANA Considerations 439 The DHCP options detailed in this document is: 441 - OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR: TBD 443 - OPTION_DNSSEC_KSK_CERT_TRUST_ANCHOR: TBD 445 - OPTION_TIME: TBD 447 11. Security Considerations 449 Security has been discussed in the "DHCP Client Behavior Section". 450 As information contained in the payloads are use to enable signature 451 validation, these pieces of information MUST be considered only when 452 issued by a trusted party, and when integrity protection is provided. 454 12. Acknowledgment 456 Bringing DNSSEC in Home Networks discussion has started during the 457 IETF87 in Berlin with Ted Lemon, Ralph Weber, Normen Kowalewski, and 458 Mikael Abrahamsson. An email discussion has also been initiated by 459 Jim Gettys with among others, helpful remarks from Paul Wouters, Joe 460 Abley, Michael Ridchardson. 462 13. References 464 13.1. Normative References 466 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 467 STD 13, RFC 1034, November 1987. 469 [RFC1035] Mockapetris, P., "Domain names - implementation and 470 specification", STD 13, RFC 1035, November 1987. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 476 and M. Carney, "Dynamic Host Configuration Protocol for 477 IPv6 (DHCPv6)", RFC 3315, July 2003. 479 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 480 Internet: Timestamps", RFC 3339, July 2002. 482 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 483 Rose, "DNS Security Introduction and Requirements", RFC 484 4033, March 2005. 486 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 487 Rose, "Resource Records for the DNS Security Extensions", 488 RFC 4034, March 2005. 490 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 491 Rose, "Protocol Modifications for the DNS Security 492 Extensions", RFC 4035, March 2005. 494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 495 Internet Protocol", RFC 4301, December 2005. 497 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 498 System (DNS)", RFC 4398, March 2006. 500 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 501 Trust Anchors", STD 74, RFC 5011, September 2007. 503 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 504 Housley, R., and W. Polk, "Internet X.509 Public Key 505 Infrastructure Certificate and Certificate Revocation List 506 (CRL) Profile", RFC 5280, May 2008. 508 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 509 Time Protocol Version 4: Protocol and Algorithms 510 Specification", RFC 5905, June 2010. 512 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 513 Server Option for DHCPv6", RFC 5908, June 2010. 515 13.2. Informational References 517 [DPS-KSK] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, 518 "DNSSEC Practice Statement for the Root Zone KSK 519 Operation", Root DNSSEC Design Team, URL: http://www 520 .root-dnssec.org/wp-content/uploads/2010/06/icann- 521 dps-00.txt, 2010. 523 [I-D.ietf-dhc-option-guidelines] 524 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 525 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 526 draft-ietf-dhc-option-guidelines-14 (work in progress), 527 September 2013. 529 [I-D.jabley-dnsop-dns-flush] 530 Abley, J., "A Mechanism for Remote-Triggered DNS Cache 531 Flushes (DNS FLUSH)", draft-jabley-dnsop-dns-flush-00 532 (work in progress), June 2013. 534 [I-D.jabley-dnsop-validator-bootstrap] 535 Abley, J. and D. Knight, "Establishing an Appropriate Root 536 Zone DNSSEC Trust Anchor at Startup", draft-jabley-dnsop- 537 validator-bootstrap-00 (work in progress), January 2011. 539 [I-D.jabley-dnssec-trust-anchor] 540 Abley, J., Schlyter, J., and G. Bailey, "DNSSEC Trust 541 Anchor Publication for the Root Zone", draft-jabley- 542 dnssec-trust-anchor-07 (work in progress), June 2013. 544 [TLSDATE] error, IO., "tlsdate: secure parasitic rdate replacement", 545 URL: https://github.com/ioerror/tlsdate, 2013. 547 Appendix A. Document Change Log 549 [RFC Editor: This section is to be removed before publication] 551 -00: First version published. 553 Author's Address 555 Daniel Migault 556 Orange 557 38 rue du General Leclerc 558 92794 Issy-les-Moulineaux Cedex 9 559 France 561 Phone: +33 1 45 29 60 52 562 Email: mglt.ietf@gmail.com