idnits 2.17.1 draft-ietf-lamps-rfc6844bis-05.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 04, 2019) is 1901 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft 4 Obsoletes: 6844 (if approved) R. Stradling 5 Intended status: Standards Track Sectigo 6 Expires: August 8, 2019 J. Hoffman-Andrews 7 Let's Encrypt 8 February 04, 2019 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-ietf-lamps-rfc6844bis-05 13 Abstract 15 The Certification Authority Authorization (CAA) DNS Resource Record 16 allows a DNS domain name holder to specify one or more Certification 17 Authorities (CAs) authorized to issue certificates for that domain 18 name. CAA Resource Records allow a public Certification Authority to 19 implement additional controls to reduce the risk of unintended 20 certificate mis-issue. This document defines the syntax of the CAA 21 record and rules for processing CAA records by certificate issuers. 23 This document obsoletes RFC 6844. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 8, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Relevant Resource Record Set . . . . . . . . . . . . . . . . 5 64 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.1. Canonical Presentation Format . . . . . . . . . . . . 7 67 4.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 8 68 4.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 9 69 4.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 10 70 4.5. Critical Flag . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 5.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 12 73 5.2. Non-Compliance by Certification Authority . . . . . . . . 12 74 5.3. Mis-Issue by Authorized Certification Authority . . . . . 12 75 5.4. Suppression or Spoofing of CAA Records . . . . . . . . . 12 76 5.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 13 77 5.6. Abuse of the Critical Flag . . . . . . . . . . . . . . . 13 78 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 79 6.1. Blocked Queries or Responses . . . . . . . . . . . . . . 14 80 6.2. Rejected Queries and Malformed Responses . . . . . . . . 14 81 6.3. Delegation to Private Nameservers . . . . . . . . . . . . 14 82 6.4. Bogus DNSSEC Responses . . . . . . . . . . . . . . . . . 14 83 7. Differences versus RFC6844 . . . . . . . . . . . . . . . . . 15 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 10.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The Certification Authority Authorization (CAA) DNS Resource Record 94 allows a DNS domain name holder to specify the Certification 95 Authorities (CAs) authorized to issue certificates for that domain 96 name. Publication of CAA Resource Records allows a public 97 Certification Authority to implement additional controls to reduce 98 the risk of unintended certificate mis-issue. 100 Like the TLSA record defined in DNS-Based Authentication of Named 101 Entities (DANE) [RFC6698], CAA records are used as a part of a 102 mechanism for checking PKIX [RFC6698] certificate data. The 103 distinction between the two specifications is that CAA records 104 specify an authorization control to be performed by a certificate 105 issuer before issue of a certificate and TLSA records specify a 106 verification control to be performed by a relying party after the 107 certificate is issued. 109 Conformance with a published CAA record is a necessary but not 110 sufficient condition for issuance of a certificate. 112 Criteria for inclusion of embedded trust anchor certificates in 113 applications are outside the scope of this document. Typically, such 114 criteria require the CA to publish a Certification Practices 115 Statement (CPS) that specifies how the requirements of the 116 Certificate Policy (CP) are achieved. It is also common for a CA to 117 engage an independent third-party auditor to prepare an annual audit 118 statement of its performance against its CPS. 120 A set of CAA records describes only current grants of authority to 121 issue certificates for the corresponding DNS domain name. Since 122 certificates are valid for a period of time, it is possible that a 123 certificate that is not conformant with the CAA records currently 124 published was conformant with the CAA records published at the time 125 that the certificate was issued. Relying parties MUST NOT use CAA 126 records as part of certificate validation. 128 CAA records MAY be used by Certificate Evaluators as a possible 129 indicator of a security policy violation. Such use SHOULD take 130 account of the possibility that published CAA records changed between 131 the time a certificate was issued and the time at which the 132 certificate was observed by the Certificate Evaluator. 134 2. Definitions 136 2.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC8174]. 142 2.2. Defined Terms 144 The following terms are used in this document: 146 Certificate: An X.509 Certificate, as specified in [RFC5280]. 148 Certificate Evaluator: A party other than a Relying Party that 149 evaluates the trustworthiness of certificates issued by Certification 150 Authorities. 152 Certification Authority (CA): An Issuer that issues certificates in 153 accordance with a specified Certificate Policy. 155 Certificate Policy (CP): Specifies the criteria that a Certification 156 Authority undertakes to meet in its issue of certificates. See 157 [RFC3647]. 159 Certification Practices Statement (CPS): Specifies the means by which 160 the criteria of the Certificate Policy are met. In most cases, this 161 will be the document against which the operations of the 162 Certification Authority are audited. See [RFC3647]. 164 Domain Name: The label assigned to a node in the Domain Name System. 166 Domain Name System (DNS): The Internet naming system specified in 167 [RFC1034] and [RFC1035]. 169 DNS Security (DNSSEC): Extensions to the DNS that provide 170 authentication services as specified in [RFC4033], [RFC4034], 171 [RFC4035], [RFC5155], and revisions. 173 Fully-Qualified Domain Name: A Domain Name that includes the labels 174 of all superior nodes in the Domain Name System. 176 Issuer: An entity that issues certificates. See [RFC5280]. 178 Property: The tag-value portion of a CAA Resource Record. 180 Property Tag: The tag portion of a CAA Resource Record. 182 Property Value: The value portion of a CAA Resource Record. 184 Resource Record (RR): A particular entry in the DNS including the 185 owner name, class, type, time to live, and data, as defined in 186 [RFC1034] and [RFC2181]. 188 Resource Record Set (RRSet): A set of Resource Records of a 189 particular owner name, class, and type. The time to live on all RRs 190 with an RRSet is always the same, but the data may be different among 191 RRs in the RRSet. 193 Relevant Resource Record Set (Relevant RRSet): A set of CAA Resource 194 Records resulting from applying the algorithm in Section 4 to a 195 specific Domain Name or Wildcard Domain Name. 197 Relying Party: A party that makes use of an application whose 198 operation depends on use of a certificate for making a security 199 decision. See [RFC5280]. 201 Wildcard Domain Name: A Domain Name consisting of a single asterisk 202 character followed by a single full stop character ("*.") followed by 203 a Fully-Qualified Domain Name. 205 3. Relevant Resource Record Set 207 Before issuing a certificate, a compliant CA MUST check for 208 publication of a Relevant RRSet. If such an RRSet exists, a CA MUST 209 NOT issue a certificate unless the CA determines that either (1) the 210 certificate request is consistent with the applicable CAA Resource 211 Record set or (2) an exception specified in the relevant Certificate 212 Policy or Certification Practices Statement applies. If the Relevant 213 RRSet for a Domain Name or Wildcard Domain Name contains no Property 214 Tags that restrict issuance (for instance, if it contains only iodef 215 Property Tags, or only Property Tags unrecognized by the CA), CAA 216 does not restrict issuance. 218 A certificate request MAY specify more than one Domain Name and MAY 219 specify Wildcard Domain Names. Issuers MUST verify authorization for 220 all the Domain Names and Wildcard Domain Names specified in the 221 request. 223 The search for a CAA RRSet climbs the DNS name tree from the 224 specified label up to but not including the DNS root '.' until a CAA 225 RRSet is found. 227 Given a request for a specific Domain Name X, or a request for a 228 Wildcard Domain Name *.X, the Relevant Resource Record Set 229 RelevantCAASet(X) is determined as follows: 231 Let CAA(X) be the RRSet returned by performing a CAA record query for 232 the Domain Name X, according to the lookup algorithm specified in RFC 233 1034 section 4.3.2 (in particular chasing aliases). Let Parent(X) be 234 the Domain Name produced by removing the leftmost label of X. 236 RelevantCAASet(domain): 237 for domain is not ".": 238 if CAA(domain) is not Empty: 239 return CAA(domain) 240 domain = Parent(domain) 241 return Empty 243 For example, processing CAA for the Domain Name "X.Y.Z" where there 244 are no CAA records at any level in the tree RelevantCAASet would have 245 the following steps: 247 CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z." 248 CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z." 249 CAA("Z.") = Empty; domain = Parent("Z.") = "." 250 return Empty 252 Processing CAA for the Domain Name "A.B.C" where there is a CAA 253 record "issue example.com" at "B.C" would terminate early upon 254 finding the CAA record: 256 CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C." 257 CAA("B.C.") = "issue example.com" 258 return "issue example.com" 260 4. Mechanism 262 4.1. Syntax 264 A CAA Resource Record contains a single Property consisting of a tag- 265 value pair. A Domain Name MAY have multiple CAA RRs associated with 266 it and a given Property Tag MAY be specified more than once across 267 those RRs. 269 The RDATA section for a CAA Resource Record contains one Property. A 270 Property consists of the following: 272 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 273 | Flags | Tag Length = n | 274 +----------------|----------------+...+---------------+ 275 | Tag char 0 | Tag char 1 |...| Tag char n-1 | 276 +----------------|----------------+...+---------------+ 277 +----------------|----------------+.....+----------------+ 278 | Value byte 0 | Value byte 1 |.....| Value byte m-1 | 279 +----------------|----------------+.....+----------------+ 281 Where n is the length specified in the Tag length field and m is the 282 remaining octets in the Value field. They are related by (m = d - n 283 - 2) where d is the length of the RDATA section. 285 The fields are defined as follows: 287 Flags: One octet containing the following field: 289 Bit 0, Issuer Critical Flag: If the value is set to '1', the Property 290 is critical. A Certification Authority MUST NOT issue certificates 291 for any Domain Name where the Relevant RRSet for that Domain Name 292 contains a CAA critical Property for an unknown or unsupported 293 Property Tag. 295 Note that according to the conventions set out in [RFC1035], bit 0 is 296 the Most Significant Bit and bit 7 is the Least Significant Bit. 297 Thus, the Flags value 1 means that bit 7 is set while a value of 128 298 means that bit 0 is set according to this convention. 300 All other bit positions are reserved for future use. 302 To ensure compatibility with future extensions to CAA, DNS records 303 compliant with this version of the CAA specification MUST clear (set 304 to "0") all reserved flags bits. Applications that interpret CAA 305 records MUST ignore the value of all reserved flag bits. 307 Tag Length: A single octet containing an unsigned integer specifying 308 the tag length in octets. The tag length MUST be at least 1 and 309 SHOULD be no more than 15. 311 Tag: The Property identifier, a sequence of US-ASCII characters. 313 Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through 314 'Z', and the numbers 0 through 9. Tags SHOULD NOT contain any other 315 characters. Matching of tags is case insensitive. 317 Tags submitted for registration by IANA MUST NOT contain any 318 characters other than the (lowercase) US-ASCII characters 'a' through 319 'z' and the numbers 0 through 9. 321 Value: A sequence of octets representing the Property Value. 322 Property Values are encoded as binary values and MAY employ sub- 323 formats. 325 The length of the value field is specified implicitly as the 326 remaining length of the enclosing RDATA section. 328 4.1.1. Canonical Presentation Format 330 The canonical presentation format of the CAA record is: 332 CAA 333 Where: 335 Flags: Is an unsigned integer between 0 and 255. 337 Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower 338 case. 340 Value: The value field, expressed as a contiguous set of characters 341 without interior spaces, or as a quoted string. See the the 342 format specified in [RFC1035], Section 5.1, but 343 note that the value field contains no length byte and is not limited 344 to 255 characters. 346 4.2. CAA issue Property 348 If the issue Property Tag is present in the Relevant RRSet for a 349 Domain Name, it is a request that Issuers 351 1. Perform CAA issue restriction processing for the Domain Name, and 353 2. Grant authorization to issue certificates containing that Domain 354 Name to the holder of the issuer-domain-name or a party acting 355 under the explicit authority of the holder of the issuer-domain- 356 name. 358 The CAA issue Property Value has the following sub-syntax (specified 359 in ABNF as per [RFC5234]). 361 issue-value = *WSP [issuer-domain-name *WSP] [";" *WSP [parameters *WSP]] 363 issuer-domain-name = label *("." label) 364 label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 366 parameters = (parameter *WSP ";" *WSP parameters) / parameter 367 parameter = tag *WSP "=" *WSP value 368 tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 369 value = *(%x21-3A / %x3C-7E) 371 For consistency with other aspects of DNS administration, Domain Name 372 values are specified in letter-digit-hyphen Label (LDH-Label) form. 374 The following CAA record set requests that no certificates be issued 375 for the Domain Name 'certs.example.com' by any Issuer other than 376 ca1.example.net or ca2.example.org. 378 certs.example.com CAA 0 issue "ca1.example.net" 379 certs.example.com CAA 0 issue "ca2.example.org" 380 Because the presence of an issue Property Tag in the Relevant RRSet 381 for a Domain Name restricts issuance, Domain Name owners can use an 382 issue Property Tag with no issuer-domain-name to request no issuance. 384 For example, the following RRSet requests that no certificates be 385 issued for the Domain Name 'nocerts.example.com' by any Issuer. 387 nocerts.example.com CAA 0 issue ";" 389 An issue Property Tag where the issue-value does not match the ABNF 390 grammar MUST be treated the same as one specifying an empty issuer- 391 domain-name. For example, the following malformed CAA RRSet forbids 392 issuance: 394 malformed.example.com CAA 0 issue "%%%%%" 396 CAA authorizations are additive; thus, the result of specifying both 397 an empty issuer-domain-name and a non-empty issuer-domain-name is the 398 same as specifying just the non-empty issuer-domain-name. 400 An Issuer MAY choose to specify parameters that further constrain the 401 issue of certificates by that Issuer, for example, specifying that 402 certificates are to be subject to specific validation polices, billed 403 to certain accounts, or issued under specific trust anchors. 405 For example, if ca1.example.net has requested its customer 406 accountable.example.com to specify their account number "230123" in 407 each of the customer's CAA records using the (CA-defined) "account" 408 parameter, it would look like this: 410 accountable.example.com CAA 0 issue "ca1.example.net; account=230123" 412 The semantics of parameters to the issue Property Tag are determined 413 by the Issuer alone. 415 4.3. CAA issuewild Property 417 The issuewild Property Tag has the same syntax and semantics as the 418 issue Property Tag except that it only grants authorization to issue 419 certificates that specify a Wildcard Domain Name and issuewild 420 properties take precedence over issue properties when specified. 421 Specifically: 423 issuewild properties MUST be ignored when processing a request for a 424 Domain Name (that is, not a Wildcard Domain Name). 426 If at least one issuewild Property is specified in the Relevant RRSet 427 for a Wildcard Domain Name, all issue properties MUST be ignored when 428 processing a request for that Wildcard Domain Name. 430 For example, the following RRSet requests that _only_ ca1.example.net 431 issue certificates for "wild.example.com" or "sub.wild.example.com", 432 and that _only_ ca2.example.org issue certificates for 433 "*.wild.example.com" or "*.sub.wild.example.com). 435 wild.example.com CAA 0 issue "ca1.example.net" 436 wild.example.com CAA 0 issuewild "ca2.example.org" 438 The following RRSet requests that _only_ ca1.example.net issue 439 certificates for "wild2.example.com", "*.wild2.example.com" or 440 "*.sub.wild2.example.com". 442 wild2.example.com CAA 0 issue "ca1.example.net" 444 The following RRSet requests that _only_ ca2.example.org issue 445 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". 446 It does not permit any Issuer to issue for "wild3.example.com" or 447 "sub.wild3.example.com". 449 wild3.example.com CAA 0 issuewild "ca2.example.org" 450 wild3.example.com CAA 0 issue ";" 452 The following RRSet requests that _only_ ca2.example.org issue 453 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". 454 It permits any Issuer to issue for "wild3.example.com" or 455 "sub.wild3.example.com". 457 wild3.example.com CAA 0 issuewild "ca2.example.org" 459 4.4. CAA iodef Property 461 The iodef Property specifies a means of reporting certificate issue 462 requests or cases of certificate issue for domains for which the 463 Property appears in the Relevant RRSet, when those requests or 464 issuances violate the security policy of the Issuer or the Domain 465 Name holder. 467 The Incident Object Description Exchange Format (IODEF) [RFC7970] is 468 used to present the incident report in machine-readable form. 470 The iodef Property Tag takes a URL as its Property Value. The URL 471 scheme type determines the method used for reporting: 473 mailto: The IODEF incident report is reported as a MIME email 474 attachment to an SMTP email that is submitted to the mail address 475 specified. The mail message sent SHOULD contain a brief text message 476 to alert the recipient to the nature of the attachment. 478 http or https: The IODEF report is submitted as a Web service request 479 to the HTTP address specified using the protocol specified in 480 [RFC6546]. 482 The following RRSet specifies that reports may be made by means of 483 email with the IODEF data as an attachment, a Web service [RFC6546], 484 or both: 486 report.example.com CAA 0 issue "ca1.example.net" 487 report.example.com CAA 0 iodef "mailto:security@example.com" 488 report.example.com CAA 0 iodef "http://iodef.example.com/" 490 4.5. Critical Flag 492 The critical flag is intended to permit future versions of CAA to 493 introduce new semantics that MUST be understood for correct 494 processing of the record, preventing conforming CAs that do not 495 recognize the new semantics from issuing certificates for the 496 indicated Domain Names. 498 In the following example, the Property with a Property Tag of 'tbs' 499 is flagged as critical. Neither the ca1.example.net CA nor any other 500 Issuer is authorized to issue for "new.example.com" (or any other 501 domains for which this is the Relevant RRSet) unless the Issuer has 502 implemented the processing rules for the 'tbs' Property Tag. 504 new.example.com CAA 0 issue "ca1.example.net" 505 new.example.com CAA 128 tbs "Unknown" 507 5. Security Considerations 509 CAA records assert a security policy that the holder of a Domain Name 510 wishes to be observed by Issuers. The effectiveness of CAA records 511 as an access control mechanism is thus dependent on observance of CAA 512 constraints by Issuers. 514 The objective of the CAA record properties described in this document 515 is to reduce the risk of certificate mis-issue rather than avoid 516 reliance on a certificate that has been mis-issued. DANE [RFC6698] 517 describes a mechanism for avoiding reliance on mis-issued 518 certificates. 520 5.1. Use of DNS Security 522 Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not 523 required. An Issuer MUST NOT issue certificates if doing so would 524 conflict with the Relevant RRSet, irrespective of whether the 525 corresponding DNS records are signed. 527 DNSSEC provides a proof of non-existence for both DNS Domain Names 528 and RRSets within Domain Names. DNSSEC verification thus enables an 529 Issuer to determine if the answer to a CAA record query is empty 530 because the RRSet is empty or if it is non-empty but the response has 531 been suppressed. 533 Use of DNSSEC allows an Issuer to acquire and archive a proof that 534 they were authorized to issue certificates for the Domain Name. 535 Verification of such archives MAY be an audit requirement to verify 536 CAA record processing compliance. Publication of such archives MAY 537 be a transparency requirement to verify CAA record processing 538 compliance. 540 5.2. Non-Compliance by Certification Authority 542 CAA records offer CAs a cost-effective means of mitigating the risk 543 of certificate mis-issue: the cost of implementing CAA checks is very 544 small and the potential costs of a mis-issue event include the 545 removal of an embedded trust anchor. 547 5.3. Mis-Issue by Authorized Certification Authority 549 Use of CAA records does not prevent mis-issue by an authorized 550 Certification Authority, i.e., a CA that is authorized to issue 551 certificates for the Domain Name in question by CAA records. 553 Domain Name holders SHOULD verify that the CAs they authorize to 554 issue certificates for their Domain Names employ appropriate controls 555 to ensure that certificates are issued only to authorized parties 556 within their organization. 558 Such controls are most appropriately determined by the Domain Name 559 holder and the authorized CA(s) directly and are thus out of scope of 560 this document. 562 5.4. Suppression or Spoofing of CAA Records 564 Suppression of the CAA record or insertion of a bogus CAA record 565 could enable an attacker to obtain a certificate from an Issuer that 566 was not authorized to issue for that Domain Name. 568 Where possible, Issuers SHOULD perform DNSSEC validation to detect 569 missing or modified CAA record sets. 571 In cases where DNSSEC is not deployed for a corresponding Domain 572 Name, an Issuer SHOULD attempt to mitigate this risk by employing 573 appropriate DNS security controls. For example, all portions of the 574 DNS lookup process SHOULD be performed against the authoritative name 575 server. Data cached by third parties MUST NOT be relied on but MAY 576 be used to support additional anti-spoofing or anti-suppression 577 controls. 579 5.5. Denial of Service 581 Introduction of a malformed or malicious CAA RR could in theory 582 enable a Denial-of-Service (DoS) attack. 584 This specific threat is not considered to add significantly to the 585 risk of running an insecure DNS service. 587 An attacker could, in principle, perform a DoS attack against an 588 Issuer by requesting a certificate with a maliciously long DNS name. 589 In practice, the DNS protocol imposes a maximum name length and CAA 590 processing does not exacerbate the existing need to mitigate DoS 591 attacks to any meaningful degree. 593 5.6. Abuse of the Critical Flag 595 A Certification Authority could make use of the critical flag to 596 trick customers into publishing records that prevent competing 597 Certification Authorities from issuing certificates even though the 598 customer intends to authorize multiple providers. 600 In practice, such an attack would be of minimal effect since any 601 competent competitor that found itself unable to issue certificates 602 due to lack of support for a Property marked critical SHOULD 603 investigate the cause and report the reason to the customer. The 604 customer will thus discover that they had been deceived. 606 6. Deployment Considerations 608 A CA implementing CAA may find that they receive errors looking up 609 CAA records. The following are some common causes of such errors, so 610 that CAs may provide guidance to their subscribers on fixing the 611 underlying problems. 613 6.1. Blocked Queries or Responses 615 Some middleboxes, in particular anti-DDoS appliances, may be 616 configured to drop DNS packets of unknown types, or may start 617 dropping such packets when they consider themselves under attack. 618 This generally manifests as a timed-out DNS query, or a SERVFAIL at a 619 local recursive resolver. 621 6.2. Rejected Queries and Malformed Responses 623 Some authoritative nameservers respond with REJECTED or NOTIMP when 624 queried for a Resource Record type they do not recognize. At least 625 one authoritative resolver produces a malformed response (with the QR 626 bit set to 0) when queried for unknown Resource Record types. Per 627 RFC 1034, the correct response for unknown Resource Record types is 628 NOERROR. 630 6.3. Delegation to Private Nameservers 632 Some Domain Name administrators make the contents of a subdomain 633 unresolvable on the public Internet by delegating that subdomain to a 634 nameserver whose IP address is private. A CA processing CAA records 635 for such subdomains will receive SERVFAIL from its recursive 636 resolver. The CA MAY interpret that as preventing issuance. Domain 637 Name administrators wishing to issue certificates for private Domain 638 Names SHOULD use split-horizon DNS with a publicly available 639 nameserver, so that CAs can receive a valid, empty CAA response for 640 those Domain Names. 642 6.4. Bogus DNSSEC Responses 644 Queries for CAA Resource Records are different from most DNS RR 645 types, because a signed, empty response to a query for CAA RRs is 646 meaningfully different from a bogus response. A signed, empty 647 response indicates that there is definitely no CAA policy set at a 648 given label. A bogus response may mean either a misconfigured zone, 649 or an attacker tampering with records. DNSSEC implementations may 650 have bugs with signatures on empty responses that go unnoticed, 651 because for more common Resource Record types like A and AAAA, the 652 difference to an end user between empty and bogus is irrelevant; they 653 both mean a site is unavailable. 655 In particular, at least two authoritative resolvers that implement 656 live signing had bugs when returning empty Resource Record sets for 657 DNSSEC-signed zones, in combination with mixed-case queries. Mixed- 658 case queries, also known as DNS 0x20, are used by some recursive 659 resolvers to increase resilience against DNS poisoning attacks. 660 DNSSEC-signing authoritative resolvers are expected to copy the same 661 capitalization from the query into their ANSWER section, but sign the 662 response as if they had use all lowercase. In particular, PowerDNS 663 versions prior to 4.0.4 had this bug. 665 7. Differences versus RFC6844 667 This document obsoletes RFC6844. The most important change is to the 668 Certification Authority Processing section. RFC6844 specified an 669 algorithm that performed DNS tree-climbing not only on the Domain 670 Name being processed, but also on all CNAMEs and DNAMEs encountered 671 along the way. This made the processing algorithm very inefficient 672 when used on Domain Names that utilize many CNAMEs, and would have 673 made it difficult for hosting providers to set CAA policies on their 674 own Domain Names without setting potentially unwanted CAA policies on 675 their customers' Domain Names. This document specifies a simplified 676 processing algorithm that only performs tree climbing on the Domain 677 Name being processed, and leaves processing of CNAMEs and DNAMEs up 678 to the CA's recursive resolver. 680 This document also includes a "Deployment Considerations" section 681 detailing experience gained with practical deployment of CAA 682 enforcement among CAs in the WebPKI. 684 This document clarifies the ABNF grammar for issue and issuewild tags 685 and resolves some inconsistencies with the document text. In 686 particular, it specifies that parameters are separated with 687 semicolons. It also allows hyphens in Property Tags. 689 This document also clarifies processing of a CAA RRset that is not 690 empty, but contains no issue or issuewild tags. 692 This document removes the section titled "The CAA RR Type," merging 693 it with "Mechanism" because the definitions were mainly duplicates. 694 It moves the "Use of DNS Security" section into Security 695 Considerations. It renames "Certification Authority Processing" to 696 "Relevant Resource Record Set," and emphasizes the use of that term 697 to more clearly define which domains are affected by a given RRset. 699 8. IANA Considerations 701 IANA is requested to add [[[ RFC Editor: Please replace with this RFC 702 ]]] as a reference for the Certification Authority Restriction Flags 703 and Certification Authority Restriction Properties registries. 705 9. Acknowledgements 707 The authors would like to thank the following people who contributed 708 to the design and documentation of this work item: Corey Bonnell, 709 Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim 710 Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger, 711 Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson. 713 10. References 715 10.1. Normative References 717 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 718 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 719 . 721 [RFC1035] Mockapetris, P., "Domain names - implementation and 722 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 723 November 1987, . 725 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 726 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 727 . 729 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 730 Rose, "DNS Security Introduction and Requirements", 731 RFC 4033, DOI 10.17487/RFC4033, March 2005, 732 . 734 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 735 Rose, "Resource Records for the DNS Security Extensions", 736 RFC 4034, DOI 10.17487/RFC4034, March 2005, 737 . 739 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 740 Rose, "Protocol Modifications for the DNS Security 741 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 742 . 744 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 745 Security (DNSSEC) Hashed Authenticated Denial of 746 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 747 . 749 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 750 Specifications: ABNF", STD 68, RFC 5234, 751 DOI 10.17487/RFC5234, January 2008, 752 . 754 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 755 Housley, R., and W. Polk, "Internet X.509 Public Key 756 Infrastructure Certificate and Certificate Revocation List 757 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 758 . 760 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 761 Defense (RID) Messages over HTTP/TLS", RFC 6546, 762 DOI 10.17487/RFC6546, April 2012, 763 . 765 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 766 of Named Entities (DANE) Transport Layer Security (TLS) 767 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 768 2012, . 770 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 771 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 772 November 2016, . 774 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 775 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 776 May 2017, . 778 10.2. Informative References 780 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 781 Wu, "Internet X.509 Public Key Infrastructure Certificate 782 Policy and Certification Practices Framework", RFC 3647, 783 DOI 10.17487/RFC3647, November 2003, 784 . 786 Authors' Addresses 788 Phillip Hallam-Baker 790 Email: phill@hallambaker.com 792 Rob Stradling 793 Sectigo Ltd. 795 Email: rob@sectigo.com 796 Jacob Hoffman-Andrews 797 Let's Encrypt 799 Email: jsha@letsencrypt.org