idnits 2.17.1 draft-ietf-lamps-rfc6844bis-06.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 (May 09, 2019) is 1811 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: November 10, 2019 J. Hoffman-Andrews 7 Let's Encrypt 8 May 09, 2019 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-ietf-lamps-rfc6844bis-06 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 November 10, 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", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2.2. Defined Terms 146 The following terms are used in this document: 148 Certificate: An X.509 Certificate, as specified in [RFC5280]. 150 Certificate Evaluator: A party other than a Relying Party that 151 evaluates the trustworthiness of certificates issued by Certification 152 Authorities. 154 Certification Authority (CA): An Issuer that issues certificates in 155 accordance with a specified Certificate Policy. 157 Certificate Policy (CP): Specifies the criteria that a Certification 158 Authority undertakes to meet in its issue of certificates. See 159 [RFC3647]. 161 Certification Practices Statement (CPS): Specifies the means by which 162 the criteria of the Certificate Policy are met. In most cases, this 163 will be the document against which the operations of the 164 Certification Authority are audited. See [RFC3647]. 166 Domain Name: The label assigned to a node in the Domain Name System. 168 Domain Name System (DNS): The Internet naming system specified in 169 [RFC1034] and [RFC1035]. 171 DNS Security (DNSSEC): Extensions to the DNS that provide 172 authentication services as specified in [RFC4033], [RFC4034], 173 [RFC4035], [RFC5155], and revisions. 175 Fully-Qualified Domain Name: A Domain Name that includes the labels 176 of all superior nodes in the Domain Name System. 178 Issuer: An entity that issues certificates. See [RFC5280]. 180 Property: The tag-value portion of a CAA Resource Record. 182 Property Tag: The tag portion of a CAA Resource Record. 184 Property Value: The value portion of a CAA Resource Record. 186 Resource Record (RR): A particular entry in the DNS including the 187 owner name, class, type, time to live, and data, as defined in 188 [RFC1034] and [RFC2181]. 190 Resource Record Set (RRSet): A set of Resource Records of a 191 particular owner name, class, and type. The time to live on all RRs 192 with an RRSet is always the same, but the data may be different among 193 RRs in the RRSet. 195 Relevant Resource Record Set (Relevant RRSet): A set of CAA Resource 196 Records resulting from applying the algorithm in Section 4 to a 197 specific Domain Name or Wildcard Domain Name. 199 Relying Party: A party that makes use of an application whose 200 operation depends on use of a certificate for making a security 201 decision. See [RFC5280]. 203 Wildcard Domain Name: A Domain Name consisting of a single asterisk 204 character followed by a single full stop character ("*.") followed by 205 a Fully-Qualified Domain Name. 207 3. Relevant Resource Record Set 209 Before issuing a certificate, a compliant CA MUST check for 210 publication of a Relevant RRSet. If such an RRSet exists, a CA MUST 211 NOT issue a certificate unless the CA determines that either (1) the 212 certificate request is consistent with the applicable CAA Resource 213 Record set or (2) an exception specified in the relevant Certificate 214 Policy or Certification Practices Statement applies. If the Relevant 215 RRSet for a Domain Name or Wildcard Domain Name contains no Property 216 Tags that restrict issuance (for instance, if it contains only iodef 217 Property Tags, or only Property Tags unrecognized by the CA), CAA 218 does not restrict issuance. 220 A certificate request MAY specify more than one Domain Name and MAY 221 specify Wildcard Domain Names. Issuers MUST verify authorization for 222 all the Domain Names and Wildcard Domain Names specified in the 223 request. 225 The search for a CAA RRSet climbs the DNS name tree from the 226 specified label up to but not including the DNS root '.' until a CAA 227 RRSet is found. 229 Given a request for a specific Domain Name X, or a request for a 230 Wildcard Domain Name *.X, the Relevant Resource Record Set 231 RelevantCAASet(X) is determined as follows: 233 Let CAA(X) be the RRSet returned by performing a CAA record query for 234 the Domain Name X, according to the lookup algorithm specified in RFC 235 1034 section 4.3.2 (in particular chasing aliases). Let Parent(X) be 236 the Domain Name produced by removing the leftmost label of X. 238 RelevantCAASet(domain): 239 for domain is not ".": 240 if CAA(domain) is not Empty: 241 return CAA(domain) 242 domain = Parent(domain) 243 return Empty 245 For example, processing CAA for the Domain Name "X.Y.Z" where there 246 are no CAA records at any level in the tree RelevantCAASet would have 247 the following steps: 249 CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z." 250 CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z." 251 CAA("Z.") = Empty; domain = Parent("Z.") = "." 252 return Empty 254 Processing CAA for the Domain Name "A.B.C" where there is a CAA 255 record "issue example.com" at "B.C" would terminate early upon 256 finding the CAA record: 258 CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C." 259 CAA("B.C.") = "issue example.com" 260 return "issue example.com" 262 4. Mechanism 264 4.1. Syntax 266 A CAA Resource Record contains a single Property consisting of a tag- 267 value pair. A Domain Name MAY have multiple CAA RRs associated with 268 it and a given Property Tag MAY be specified more than once across 269 those RRs. 271 The RDATA section for a CAA Resource Record contains one Property. A 272 Property consists of the following: 274 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 275 | Flags | Tag Length = n | 276 +----------------|----------------+...+---------------+ 277 | Tag char 0 | Tag char 1 |...| Tag char n-1 | 278 +----------------|----------------+...+---------------+ 279 +----------------|----------------+.....+----------------+ 280 | Value byte 0 | Value byte 1 |.....| Value byte m-1 | 281 +----------------|----------------+.....+----------------+ 283 Where n is the length specified in the Tag length field and m is the 284 remaining octets in the Value field. They are related by (m = d - n 285 - 2) where d is the length of the RDATA section. 287 The fields are defined as follows: 289 Flags: One octet containing the following field: 291 Bit 0, Issuer Critical Flag: If the value is set to '1', the Property 292 is critical. A Certification Authority MUST NOT issue certificates 293 for any Domain Name where the Relevant RRSet for that Domain Name 294 contains a CAA critical Property for an unknown or unsupported 295 Property Tag. 297 Note that according to the conventions set out in [RFC1035], bit 0 is 298 the Most Significant Bit and bit 7 is the Least Significant Bit. 299 Thus, the Flags value 1 means that bit 7 is set while a value of 128 300 means that bit 0 is set according to this convention. 302 All other bit positions are reserved for future use. 304 To ensure compatibility with future extensions to CAA, DNS records 305 compliant with this version of the CAA specification MUST clear (set 306 to "0") all reserved flags bits. Applications that interpret CAA 307 records MUST ignore the value of all reserved flag bits. 309 Tag Length: A single octet containing an unsigned integer specifying 310 the tag length in octets. The tag length MUST be at least 1 and 311 SHOULD be no more than 15. 313 Tag: The Property identifier, a sequence of US-ASCII characters. 315 Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through 316 'Z', and the numbers 0 through 9. Tags SHOULD NOT contain any other 317 characters. Matching of tags is case insensitive. 319 Tags submitted for registration by IANA MUST NOT contain any 320 characters other than the (lowercase) US-ASCII characters 'a' through 321 'z' and the numbers 0 through 9. 323 Value: A sequence of octets representing the Property Value. 324 Property Values are encoded as binary values and MAY employ sub- 325 formats. 327 The length of the value field is specified implicitly as the 328 remaining length of the enclosing RDATA section. 330 4.1.1. Canonical Presentation Format 332 The canonical presentation format of the CAA record is: 334 CAA 335 Where: 337 Flags: Is an unsigned integer between 0 and 255. 339 Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower 340 case. 342 Value: The value field, expressed as a contiguous set of characters 343 without interior spaces, or as a quoted string. See the the 344 format specified in [RFC1035], Section 5.1, but 345 note that the value field contains no length byte and is not limited 346 to 255 characters. 348 4.2. CAA issue Property 350 If the issue Property Tag is present in the Relevant RRSet for a 351 Domain Name, it is a request that Issuers 353 1. Perform CAA issue restriction processing for the Domain Name, and 355 2. Grant authorization to issue certificates containing that Domain 356 Name to the holder of the issuer-domain-name or a party acting 357 under the explicit authority of the holder of the issuer-domain- 358 name. 360 The CAA issue Property Value has the following sub-syntax (specified 361 in ABNF as per [RFC5234]). 363 issue-value = *WSP [issuer-domain-name *WSP] [";" *WSP [parameters *WSP]] 365 issuer-domain-name = label *("." label) 366 label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 368 parameters = (parameter *WSP ";" *WSP parameters) / parameter 369 parameter = tag *WSP "=" *WSP value 370 tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 371 value = *(%x21-3A / %x3C-7E) 373 For consistency with other aspects of DNS administration, Domain Name 374 values are specified in letter-digit-hyphen Label (LDH-Label) form. 376 The following CAA record set requests that no certificates be issued 377 for the Domain Name 'certs.example.com' by any Issuer other than 378 ca1.example.net or ca2.example.org. 380 certs.example.com CAA 0 issue "ca1.example.net" 381 certs.example.com CAA 0 issue "ca2.example.org" 382 Because the presence of an issue Property Tag in the Relevant RRSet 383 for a Domain Name restricts issuance, Domain Name owners can use an 384 issue Property Tag with no issuer-domain-name to request no issuance. 386 For example, the following RRSet requests that no certificates be 387 issued for the Domain Name 'nocerts.example.com' by any Issuer. 389 nocerts.example.com CAA 0 issue ";" 391 An issue Property Tag where the issue-value does not match the ABNF 392 grammar MUST be treated the same as one specifying an empty issuer- 393 domain-name. For example, the following malformed CAA RRSet forbids 394 issuance: 396 malformed.example.com CAA 0 issue "%%%%%" 398 CAA authorizations are additive; thus, the result of specifying both 399 an empty issuer-domain-name and a non-empty issuer-domain-name is the 400 same as specifying just the non-empty issuer-domain-name. 402 An Issuer MAY choose to specify parameters that further constrain the 403 issue of certificates by that Issuer, for example, specifying that 404 certificates are to be subject to specific validation polices, billed 405 to certain accounts, or issued under specific trust anchors. 407 For example, if ca1.example.net has requested its customer 408 accountable.example.com to specify their account number "230123" in 409 each of the customer's CAA records using the (CA-defined) "account" 410 parameter, it would look like this: 412 accountable.example.com CAA 0 issue "ca1.example.net; account=230123" 414 The semantics of parameters to the issue Property Tag are determined 415 by the Issuer alone. 417 4.3. CAA issuewild Property 419 The issuewild Property Tag has the same syntax and semantics as the 420 issue Property Tag except that it only grants authorization to issue 421 certificates that specify a Wildcard Domain Name and issuewild 422 properties take precedence over issue properties when specified. 423 Specifically: 425 issuewild properties MUST be ignored when processing a request for a 426 Domain Name (that is, not a Wildcard Domain Name). 428 If at least one issuewild Property is specified in the Relevant RRSet 429 for a Wildcard Domain Name, all issue properties MUST be ignored when 430 processing a request for that Wildcard Domain Name. 432 For example, the following RRSet requests that _only_ ca1.example.net 433 issue certificates for "wild.example.com" or "sub.wild.example.com", 434 and that _only_ ca2.example.org issue certificates for 435 "*.wild.example.com" or "*.sub.wild.example.com). 437 wild.example.com CAA 0 issue "ca1.example.net" 438 wild.example.com CAA 0 issuewild "ca2.example.org" 440 The following RRSet requests that _only_ ca1.example.net issue 441 certificates for "wild2.example.com", "*.wild2.example.com" or 442 "*.sub.wild2.example.com". 444 wild2.example.com CAA 0 issue "ca1.example.net" 446 The following RRSet requests that _only_ ca2.example.org issue 447 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". 448 It does not permit any Issuer to issue for "wild3.example.com" or 449 "sub.wild3.example.com". 451 wild3.example.com CAA 0 issuewild "ca2.example.org" 452 wild3.example.com CAA 0 issue ";" 454 The following RRSet requests that _only_ ca2.example.org issue 455 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". 456 It permits any Issuer to issue for "wild3.example.com" or 457 "sub.wild3.example.com". 459 wild3.example.com CAA 0 issuewild "ca2.example.org" 461 4.4. CAA iodef Property 463 The iodef Property specifies a means of reporting certificate issue 464 requests or cases of certificate issue for domains for which the 465 Property appears in the Relevant RRSet, when those requests or 466 issuances violate the security policy of the Issuer or the Domain 467 Name holder. 469 The Incident Object Description Exchange Format (IODEF) [RFC7970] is 470 used to present the incident report in machine-readable form. 472 The iodef Property Tag takes a URL as its Property Value. The URL 473 scheme type determines the method used for reporting: 475 mailto: The IODEF incident report is reported as a MIME email 476 attachment to an SMTP email that is submitted to the mail address 477 specified. The mail message sent SHOULD contain a brief text message 478 to alert the recipient to the nature of the attachment. 480 http or https: The IODEF report is submitted as a Web service request 481 to the HTTP address specified using the protocol specified in 482 [RFC6546]. 484 The following RRSet specifies that reports may be made by means of 485 email with the IODEF data as an attachment, a Web service [RFC6546], 486 or both: 488 report.example.com CAA 0 issue "ca1.example.net" 489 report.example.com CAA 0 iodef "mailto:security@example.com" 490 report.example.com CAA 0 iodef "http://iodef.example.com/" 492 4.5. Critical Flag 494 The critical flag is intended to permit future versions of CAA to 495 introduce new semantics that MUST be understood for correct 496 processing of the record, preventing conforming CAs that do not 497 recognize the new semantics from issuing certificates for the 498 indicated Domain Names. 500 In the following example, the Property with a Property Tag of 'tbs' 501 is flagged as critical. Neither the ca1.example.net CA nor any other 502 Issuer is authorized to issue for "new.example.com" (or any other 503 domains for which this is the Relevant RRSet) unless the Issuer has 504 implemented the processing rules for the 'tbs' Property Tag. 506 new.example.com CAA 0 issue "ca1.example.net" 507 new.example.com CAA 128 tbs "Unknown" 509 5. Security Considerations 511 CAA records assert a security policy that the holder of a Domain Name 512 wishes to be observed by Issuers. The effectiveness of CAA records 513 as an access control mechanism is thus dependent on observance of CAA 514 constraints by Issuers. 516 The objective of the CAA record properties described in this document 517 is to reduce the risk of certificate mis-issue rather than avoid 518 reliance on a certificate that has been mis-issued. DANE [RFC6698] 519 describes a mechanism for avoiding reliance on mis-issued 520 certificates. 522 5.1. Use of DNS Security 524 Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not 525 required. An Issuer MUST NOT issue certificates if doing so would 526 conflict with the Relevant RRSet, irrespective of whether the 527 corresponding DNS records are signed. 529 DNSSEC provides a proof of non-existence for both DNS Domain Names 530 and RRSets within Domain Names. DNSSEC verification thus enables an 531 Issuer to determine if the answer to a CAA record query is empty 532 because the RRSet is empty or if it is non-empty but the response has 533 been suppressed. 535 Use of DNSSEC allows an Issuer to acquire and archive a proof that 536 they were authorized to issue certificates for the Domain Name. 537 Verification of such archives MAY be an audit requirement to verify 538 CAA record processing compliance. Publication of such archives MAY 539 be a transparency requirement to verify CAA record processing 540 compliance. 542 5.2. Non-Compliance by Certification Authority 544 CAA records offer CAs a cost-effective means of mitigating the risk 545 of certificate mis-issue: the cost of implementing CAA checks is very 546 small and the potential costs of a mis-issue event include the 547 removal of an embedded trust anchor. 549 5.3. Mis-Issue by Authorized Certification Authority 551 Use of CAA records does not prevent mis-issue by an authorized 552 Certification Authority, i.e., a CA that is authorized to issue 553 certificates for the Domain Name in question by CAA records. 555 Domain Name holders SHOULD verify that the CAs they authorize to 556 issue certificates for their Domain Names employ appropriate controls 557 to ensure that certificates are issued only to authorized parties 558 within their organization. 560 Such controls are most appropriately determined by the Domain Name 561 holder and the authorized CA(s) directly and are thus out of scope of 562 this document. 564 5.4. Suppression or Spoofing of CAA Records 566 Suppression of the CAA record or insertion of a bogus CAA record 567 could enable an attacker to obtain a certificate from an Issuer that 568 was not authorized to issue for that Domain Name. 570 Where possible, Issuers SHOULD perform DNSSEC validation to detect 571 missing or modified CAA record sets. 573 In cases where DNSSEC is not deployed for a corresponding Domain 574 Name, an Issuer SHOULD attempt to mitigate this risk by employing 575 appropriate DNS security controls. For example, all portions of the 576 DNS lookup process SHOULD be performed against the authoritative name 577 server. Data cached by third parties MUST NOT be relied on but MAY 578 be used to support additional anti-spoofing or anti-suppression 579 controls. 581 5.5. Denial of Service 583 Introduction of a malformed or malicious CAA RR could in theory 584 enable a Denial-of-Service (DoS) attack. 586 This specific threat is not considered to add significantly to the 587 risk of running an insecure DNS service. 589 An attacker could, in principle, perform a DoS attack against an 590 Issuer by requesting a certificate with a maliciously long DNS name. 591 In practice, the DNS protocol imposes a maximum name length and CAA 592 processing does not exacerbate the existing need to mitigate DoS 593 attacks to any meaningful degree. 595 5.6. Abuse of the Critical Flag 597 A Certification Authority could make use of the critical flag to 598 trick customers into publishing records that prevent competing 599 Certification Authorities from issuing certificates even though the 600 customer intends to authorize multiple providers. 602 In practice, such an attack would be of minimal effect since any 603 competent competitor that found itself unable to issue certificates 604 due to lack of support for a Property marked critical SHOULD 605 investigate the cause and report the reason to the customer. The 606 customer will thus discover that they had been deceived. 608 6. Deployment Considerations 610 A CA implementing CAA may find that they receive errors looking up 611 CAA records. The following are some common causes of such errors, so 612 that CAs may provide guidance to their subscribers on fixing the 613 underlying problems. 615 6.1. Blocked Queries or Responses 617 Some middleboxes, in particular anti-DDoS appliances, may be 618 configured to drop DNS packets of unknown types, or may start 619 dropping such packets when they consider themselves under attack. 620 This generally manifests as a timed-out DNS query, or a SERVFAIL at a 621 local recursive resolver. 623 6.2. Rejected Queries and Malformed Responses 625 Some authoritative nameservers respond with REJECTED or NOTIMP when 626 queried for a Resource Record type they do not recognize. At least 627 one authoritative resolver produces a malformed response (with the QR 628 bit set to 0) when queried for unknown Resource Record types. Per 629 RFC 1034, the correct response for unknown Resource Record types is 630 NOERROR. 632 6.3. Delegation to Private Nameservers 634 Some Domain Name administrators make the contents of a subdomain 635 unresolvable on the public Internet by delegating that subdomain to a 636 nameserver whose IP address is private. A CA processing CAA records 637 for such subdomains will receive SERVFAIL from its recursive 638 resolver. The CA MAY interpret that as preventing issuance. Domain 639 Name administrators wishing to issue certificates for private Domain 640 Names SHOULD use split-horizon DNS with a publicly available 641 nameserver, so that CAs can receive a valid, empty CAA response for 642 those Domain Names. 644 6.4. Bogus DNSSEC Responses 646 Queries for CAA Resource Records are different from most DNS RR 647 types, because a signed, empty response to a query for CAA RRs is 648 meaningfully different from a bogus response. A signed, empty 649 response indicates that there is definitely no CAA policy set at a 650 given label. A bogus response may mean either a misconfigured zone, 651 or an attacker tampering with records. DNSSEC implementations may 652 have bugs with signatures on empty responses that go unnoticed, 653 because for more common Resource Record types like A and AAAA, the 654 difference to an end user between empty and bogus is irrelevant; they 655 both mean a site is unavailable. 657 In particular, at least two authoritative resolvers that implement 658 live signing had bugs when returning empty Resource Record sets for 659 DNSSEC-signed zones, in combination with mixed-case queries. Mixed- 660 case queries, also known as DNS 0x20, are used by some recursive 661 resolvers to increase resilience against DNS poisoning attacks. 662 DNSSEC-signing authoritative resolvers are expected to copy the same 663 capitalization from the query into their ANSWER section, but sign the 664 response as if they had use all lowercase. In particular, PowerDNS 665 versions prior to 4.0.4 had this bug. 667 7. Differences versus RFC6844 669 This document obsoletes RFC6844. The most important change is to the 670 Certification Authority Processing section. RFC6844 specified an 671 algorithm that performed DNS tree-climbing not only on the Domain 672 Name being processed, but also on all CNAMEs and DNAMEs encountered 673 along the way. This made the processing algorithm very inefficient 674 when used on Domain Names that utilize many CNAMEs, and would have 675 made it difficult for hosting providers to set CAA policies on their 676 own Domain Names without setting potentially unwanted CAA policies on 677 their customers' Domain Names. This document specifies a simplified 678 processing algorithm that only performs tree climbing on the Domain 679 Name being processed, and leaves processing of CNAMEs and DNAMEs up 680 to the CA's recursive resolver. 682 This document also includes a "Deployment Considerations" section 683 detailing experience gained with practical deployment of CAA 684 enforcement among CAs in the WebPKI. 686 This document clarifies the ABNF grammar for issue and issuewild tags 687 and resolves some inconsistencies with the document text. In 688 particular, it specifies that parameters are separated with 689 semicolons. It also allows hyphens in Property Tags. 691 This document also clarifies processing of a CAA RRset that is not 692 empty, but contains no issue or issuewild tags. 694 This document removes the section titled "The CAA RR Type," merging 695 it with "Mechanism" because the definitions were mainly duplicates. 696 It moves the "Use of DNS Security" section into Security 697 Considerations. It renames "Certification Authority Processing" to 698 "Relevant Resource Record Set," and emphasizes the use of that term 699 to more clearly define which domains are affected by a given RRset. 701 8. IANA Considerations 703 IANA is requested to add [[[ RFC Editor: Please replace with this RFC 704 ]]] as a reference for the Certification Authority Restriction Flags 705 and Certification Authority Restriction Properties registries. 707 9. Acknowledgements 709 The authors would like to thank the following people who contributed 710 to the design and documentation of this work item: Corey Bonnell, 711 Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim 712 Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger, 713 Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson. 715 10. References 717 10.1. Normative References 719 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 720 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 721 . 723 [RFC1035] Mockapetris, P., "Domain names - implementation and 724 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 725 November 1987, . 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 729 DOI 10.17487/RFC2119, March 1997, 730 . 732 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 733 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 734 . 736 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 737 Rose, "DNS Security Introduction and Requirements", 738 RFC 4033, DOI 10.17487/RFC4033, March 2005, 739 . 741 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 742 Rose, "Resource Records for the DNS Security Extensions", 743 RFC 4034, DOI 10.17487/RFC4034, March 2005, 744 . 746 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 747 Rose, "Protocol Modifications for the DNS Security 748 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 749 . 751 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 752 Security (DNSSEC) Hashed Authenticated Denial of 753 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 754 . 756 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 757 Specifications: ABNF", STD 68, RFC 5234, 758 DOI 10.17487/RFC5234, January 2008, 759 . 761 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 762 Housley, R., and W. Polk, "Internet X.509 Public Key 763 Infrastructure Certificate and Certificate Revocation List 764 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 765 . 767 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 768 Defense (RID) Messages over HTTP/TLS", RFC 6546, 769 DOI 10.17487/RFC6546, April 2012, 770 . 772 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 773 of Named Entities (DANE) Transport Layer Security (TLS) 774 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 775 2012, . 777 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 778 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 779 November 2016, . 781 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 782 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 783 May 2017, . 785 10.2. Informative References 787 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 788 Wu, "Internet X.509 Public Key Infrastructure Certificate 789 Policy and Certification Practices Framework", RFC 3647, 790 DOI 10.17487/RFC3647, November 2003, 791 . 793 Authors' Addresses 795 Phillip Hallam-Baker 797 Email: phill@hallambaker.com 799 Rob Stradling 800 Sectigo Ltd. 802 Email: rob@sectigo.com 803 Jacob Hoffman-Andrews 804 Let's Encrypt 806 Email: jsha@letsencrypt.org