idnits 2.17.1 draft-ietf-lamps-rfc6844bis-07.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 30, 2019) is 1792 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 6844 (Obsoleted by RFC 8659) Summary: 2 errors (**), 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: December 1, 2019 J. Hoffman-Andrews 7 Let's Encrypt 8 May 30, 2019 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-ietf-lamps-rfc6844bis-07 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 December 1, 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 (FQDN): A Domain Name that includes the 176 labels 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 within an RRSet is always the same, but the data may be different 193 among 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 3 to a 197 specific Fully-Qualified 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 Fully-Qualified Domain Name or Wildcard Domain Name 216 contains no Property Tags that restrict issuance (for instance, if it 217 contains only iodef Property Tags, or only Property Tags unrecognized 218 by the CA), CAA does not restrict issuance. 220 A certificate request MAY specify more than one Fully-Qualified 221 Domain Name and MAY specify Wildcard Domain Names. Issuers MUST 222 verify authorization for all the Fully-Qualified Domain Names and 223 Wildcard Domain Names specified in the 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 Fully-Qualified Domain Name X, or a 230 request for a Wildcard Domain Name *.X, the Relevant Resource Record 231 Set RelevantCAASet(X) is determined as follows (in pseudocode): 233 Let CAA(X) be the RRSet returned by performing a CAA record query for 234 the Fully-Qualified Domain Name X, according to the lookup algorithm 235 specified in RFC 1034 section 4.3.2 (in particular chasing aliases). 236 Let Parent(X) be the Fully-Qualified Domain Name produced by removing 237 the leftmost label of X. 239 RelevantCAASet(domain): 240 while domain is not ".": 241 if CAA(domain) is not Empty: 242 return CAA(domain) 243 domain = Parent(domain) 244 return Empty 246 For example, processing CAA for the Fully-Qualified Domain Name 247 "X.Y.Z" where there are no CAA records at any level in the tree 248 RelevantCAASet would have the following steps: 250 CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z." 251 CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z." 252 CAA("Z.") = Empty; domain = Parent("Z.") = "." 253 return Empty 255 Processing CAA for the Fully-Qualified Domain Name "A.B.C" where 256 there is a CAA record "issue example.com" at "B.C" would terminate 257 early upon finding the CAA record: 259 CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C." 260 CAA("B.C.") = "issue example.com" 261 return "issue example.com" 263 4. Mechanism 265 4.1. Syntax 267 A CAA Resource Record contains a single Property consisting of a tag- 268 value pair. A Fully-Qualified Domain Name MAY have multiple CAA RRs 269 associated with it and a given Property Tag MAY be specified more 270 than once across those RRs. 272 The RDATA section for a CAA Resource Record contains one Property. A 273 Property consists of the following: 275 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 276 | Flags | Tag Length = n | 277 +----------------|----------------+...+---------------+ 278 | Tag char 0 | Tag char 1 |...| Tag char n-1 | 279 +----------------|----------------+...+---------------+ 280 +----------------|----------------+.....+----------------+ 281 | Value byte 0 | Value byte 1 |.....| Value byte m-1 | 282 +----------------|----------------+.....+----------------+ 284 Where n is the length specified in the Tag length field and m is the 285 remaining octets in the Value field. They are related by (m = d - n 286 - 2) where d is the length of the RDATA section. 288 The fields are defined as follows: 290 Flags: One octet containing the following field: 292 Bit 0, Issuer Critical Flag: If the value is set to '1', the Property 293 is critical. A Certification Authority MUST NOT issue certificates 294 for any FQDN the Relevant RRSet for that FQDN contains a CAA critical 295 Property for an unknown or unsupported 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. 312 Tag: The Property identifier, a sequence of US-ASCII characters. 314 Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through 315 'Z', and the numbers 0 through 9. Tags MUST NOT contain any other 316 characters. Matching of tags is case insensitive. 318 Tags submitted for registration by IANA MUST NOT contain any 319 characters other than the (lowercase) US-ASCII characters 'a' through 320 'z' and the numbers 0 through 9. 322 Value: A sequence of octets representing the Property Value. 323 Property Values are encoded as binary values and MAY employ sub- 324 formats. 326 The length of the value field is specified implicitly as the 327 remaining length of the enclosing RDATA section. 329 4.1.1. Canonical Presentation Format 331 The canonical presentation format of the CAA record is: 333 CAA 335 Where: 337 Flags: Is an unsigned integer between 0 and 255. 339 Tag: Is a non-zero-length sequence of US-ASCII letters and numbers in 340 lower case. 342 Value: The value field, expressed as a contiguous set of characters 343 without interior spaces, or as a quoted string. See the format specified in [RFC1035], Section 5.1, but note that the 345 value field contains no length byte and is not limited to 255 346 characters. 348 4.2. CAA issue Property 350 If the issue Property Tag is present in the Relevant RRSet for a 351 Fully-Qualified Domain Name, it is a request that Issuers 353 1. Perform CAA issue restriction processing for the FQDN, and 355 2. Grant authorization to issue certificates containing that FQDN to 356 the holder of the issuer-domain-name or a party acting under the 357 explicit authority of the holder of the issuer-domain-name. 359 The CAA issue Property Value has the following sub-syntax (specified 360 in ABNF as per [RFC5234]). 362 issue-value = *WSP [issuer-domain-name *WSP] [";" *WSP [parameters *WSP]] 364 issuer-domain-name = label *("." label) 365 label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 367 parameters = (parameter *WSP ";" *WSP parameters) / parameter 368 parameter = tag *WSP "=" *WSP value 369 tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 370 value = *(%x21-3A / %x3C-7E) 372 For consistency with other aspects of DNS administration, FQDN values 373 are specified in letter-digit-hyphen Label (LDH-Label) form. 375 The following CAA record set requests that no certificates be issued 376 for the FQDN 'certs.example.com' by any Issuer other than 377 ca1.example.net or ca2.example.org. 379 certs.example.com CAA 0 issue "ca1.example.net" 380 certs.example.com CAA 0 issue "ca2.example.org" 382 Because the presence of an issue Property Tag in the Relevant RRSet 383 for an FQDN restricts issuance, FQDN owners can use an issue Property 384 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 FQDN '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 Fully-Qualified 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). Note that this 436 presumes there are no CAA RRs for sub.wild.example.com. 438 wild.example.com CAA 0 issue "ca1.example.net" 439 wild.example.com CAA 0 issuewild "ca2.example.org" 441 The following RRSet requests that _only_ ca1.example.net issue 442 certificates for "wild2.example.com", "*.wild2.example.com" or 443 "*.sub.wild2.example.com". 445 wild2.example.com CAA 0 issue "ca1.example.net" 447 The following RRSet requests that _only_ ca2.example.org issue 448 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". 449 It does not permit any Issuer to issue for "wild3.example.com" or 450 "sub.wild3.example.com". 452 wild3.example.com CAA 0 issuewild "ca2.example.org" 453 wild3.example.com CAA 0 issue ";" 455 The following RRSet requests that _only_ ca2.example.org issue 456 certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". 457 It permits any Issuer to issue for "wild3.example.com" or 458 "sub.wild3.example.com". 460 wild3.example.com CAA 0 issuewild "ca2.example.org" 462 4.4. CAA iodef Property 464 The iodef Property specifies a means of reporting certificate issue 465 requests or cases of certificate issue for domains for which the 466 Property appears in the Relevant RRSet, when those requests or 467 issuances violate the security policy of the Issuer or the FQDN 468 holder. 470 The Incident Object Description Exchange Format (IODEF) [RFC7970] is 471 used to present the incident report in machine-readable form. 473 The iodef Property Tag takes a URL as its Property Value. The URL 474 scheme type determines the method used for reporting: 476 mailto: The IODEF incident report is reported as a MIME email 477 attachment to an SMTP email that is submitted to the mail address 478 specified. The mail message sent SHOULD contain a brief text message 479 to alert the recipient to the nature of the attachment. 481 http or https: The IODEF report is submitted as a Web service request 482 to the HTTP address specified using the protocol specified in 483 [RFC6546]. 485 These are the only supported URL schemes. 487 The following RRSet specifies that reports may be made by means of 488 email with the IODEF data as an attachment, a Web service [RFC6546], 489 or both: 491 report.example.com CAA 0 issue "ca1.example.net" 492 report.example.com CAA 0 iodef "mailto:security@example.com" 493 report.example.com CAA 0 iodef "http://iodef.example.com/" 495 4.5. Critical Flag 497 The critical flag is intended to permit future versions of CAA to 498 introduce new semantics that MUST be understood for correct 499 processing of the record, preventing conforming CAs that do not 500 recognize the new semantics from issuing certificates for the 501 indicated FQDNs. 503 In the following example, the Property with a Property Tag of 'tbs' 504 is flagged as critical. Neither the ca1.example.net CA nor any other 505 Issuer is authorized to issue for "new.example.com" (or any other 506 domains for which this is the Relevant RRSet) unless the Issuer has 507 implemented the processing rules for the 'tbs' Property Tag. 509 new.example.com CAA 0 issue "ca1.example.net" 510 new.example.com CAA 128 tbs "Unknown" 512 5. Security Considerations 514 CAA records assert a security policy that the holder of an FDQN 515 wishes to be observed by Issuers. The effectiveness of CAA records 516 as an access control mechanism is thus dependent on observance of CAA 517 constraints by Issuers. 519 The objective of the CAA record properties described in this document 520 is to reduce the risk of certificate mis-issue rather than avoid 521 reliance on a certificate that has been mis-issued. DANE [RFC6698] 522 describes a mechanism for avoiding reliance on mis-issued 523 certificates. 525 5.1. Use of DNS Security 527 Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not 528 required. An Issuer MUST NOT issue certificates if doing so would 529 conflict with the Relevant RRSet, irrespective of whether the 530 corresponding DNS records are signed. 532 DNSSEC provides a proof of non-existence for both DNS Fully-Qualified 533 Domain Names and RRSets within FQDNs. DNSSEC verification thus 534 enables an Issuer to determine if the answer to a CAA record query is 535 empty because the RRSet is empty or if it is non-empty but the 536 response has been suppressed. 538 Use of DNSSEC allows an Issuer to acquire and archive a proof that 539 they were authorized to issue certificates for the FQDN. 540 Verification of such archives may be an audit requirement to verify 541 CAA record processing compliance. Publication of such archives may 542 be a transparency requirement to verify CAA record processing 543 compliance. 545 5.2. Non-Compliance by Certification Authority 547 CAA records offer CAs a cost-effective means of mitigating the risk 548 of certificate mis-issue: the cost of implementing CAA checks is very 549 small and the potential costs of a mis-issue event include the 550 removal of an embedded trust anchor. 552 5.3. Mis-Issue by Authorized Certification Authority 554 Use of CAA records does not prevent mis-issue by an authorized 555 Certification Authority, i.e., a CA that is authorized to issue 556 certificates for the FQDN in question by CAA records. 558 FQDN holders SHOULD verify that the CAs they authorize to issue 559 certificates for their FQDNs employ appropriate controls to ensure 560 that certificates are issued only to authorized parties within their 561 organization. 563 Such controls are most appropriately determined by the FQDN holder 564 and the authorized CA(s) directly and are thus out of scope of this 565 document. 567 5.4. Suppression or Spoofing of CAA Records 569 Suppression of the CAA record or insertion of a bogus CAA record 570 could enable an attacker to obtain a certificate from an Issuer that 571 was not authorized to issue for an affected FQDN. 573 Where possible, Issuers SHOULD perform DNSSEC validation to detect 574 missing or modified CAA record sets. 576 In cases where DNSSEC is not deployed for a corresponding FQDN, an 577 Issuer SHOULD attempt to mitigate this risk by employing appropriate 578 DNS security controls. For example, all portions of the DNS lookup 579 process SHOULD be performed against the authoritative name server. 580 Data cached by third parties MUST NOT be relied on as the sole source 581 of DNS CAA information but MAY be used to support additional anti- 582 spoofing or anti-suppression controls. 584 5.5. Denial of Service 586 Introduction of a malformed or malicious CAA RR could in theory 587 enable a Denial-of-Service (DoS) attack. This could happen by 588 modification of authoritative DNS records or by spoofing inflight DNS 589 responses. 591 This specific threat is not considered to add significantly to the 592 risk of running an insecure DNS service. 594 An attacker could, in principle, perform a DoS attack against an 595 Issuer by requesting a certificate with a maliciously long DNS name. 596 In practice, the DNS protocol imposes a maximum name length and CAA 597 processing does not exacerbate the existing need to mitigate DoS 598 attacks to any meaningful degree. 600 5.6. Abuse of the Critical Flag 602 A Certification Authority could make use of the critical flag to 603 trick customers into publishing records that prevent competing 604 Certification Authorities from issuing certificates even though the 605 customer intends to authorize multiple providers. This could happen 606 if the customers were setting CAA records based on data provided by 607 the CA rather than generating those records themselves. 609 In practice, such an attack would be of minimal effect since any 610 competent competitor that found itself unable to issue certificates 611 due to lack of support for a Property marked critical should 612 investigate the cause and report the reason to the customer. The 613 customer will thus discover that they had been deceived. 615 6. Deployment Considerations 617 A CA implementing CAA may find that they receive errors looking up 618 CAA records. The following are some common causes of such errors, so 619 that CAs may provide guidance to their subscribers on fixing the 620 underlying problems. 622 6.1. Blocked Queries or Responses 624 Some middleboxes, in particular anti-DDoS appliances, may be 625 configured to drop DNS packets of unknown types, or may start 626 dropping such packets when they consider themselves under attack. 627 This generally manifests as a timed-out DNS query, or a SERVFAIL at a 628 local recursive resolver. 630 6.2. Rejected Queries and Malformed Responses 632 Some authoritative nameservers respond with REJECTED or NOTIMP when 633 queried for a Resource Record type they do not recognize. At least 634 one authoritative resolver produces a malformed response (with the QR 635 bit set to 0) when queried for unknown Resource Record types. Per 636 RFC 1034, the correct response for unknown Resource Record types is 637 NOERROR. 639 6.3. Delegation to Private Nameservers 641 Some FQDN administrators make the contents of a subdomain 642 unresolvable on the public Internet by delegating that subdomain to a 643 nameserver whose IP address is private. A CA processing CAA records 644 for such subdomains will receive SERVFAIL from its recursive 645 resolver. The CA MAY interpret that as preventing issuance. FQDN 646 administrators wishing to issue certificates for private FQDNs SHOULD 647 use split-horizon DNS with a publicly available nameserver, so that 648 CAs can receive a valid, empty CAA response for those FQDNs. 650 6.4. Bogus DNSSEC Responses 652 Queries for CAA Resource Records are different from most DNS RR 653 types, because a signed, empty response to a query for CAA RRs is 654 meaningfully different from a bogus response. A signed, empty 655 response indicates that there is definitely no CAA policy set at a 656 given label. A bogus response may mean either a misconfigured zone, 657 or an attacker tampering with records. DNSSEC implementations may 658 have bugs with signatures on empty responses that go unnoticed, 659 because for more common Resource Record types like A and AAAA, the 660 difference to an end user between empty and bogus is irrelevant; they 661 both mean a site is unavailable. 663 In particular, at least two authoritative resolvers that implement 664 live signing had bugs when returning empty Resource Record sets for 665 DNSSEC-signed zones, in combination with mixed-case queries. Mixed- 666 case queries, also known as DNS 0x20, are used by some recursive 667 resolvers to increase resilience against DNS poisoning attacks. 668 DNSSEC-signing authoritative resolvers are expected to copy the same 669 capitalization from the query into their ANSWER section, but sign the 670 response as if they had used all lowercase. In particular, PowerDNS 671 versions prior to 4.0.4 had this bug. 673 7. Differences versus RFC6844 675 This document obsoletes RFC6844. The most important change is to the 676 Certification Authority Processing section. RFC6844 specified an 677 algorithm that performed DNS tree-climbing not only on the FQDN being 678 processed, but also on all CNAMEs and DNAMEs encountered along the 679 way. This made the processing algorithm very inefficient when used 680 on FQDNs that utilize many CNAMEs, and would have made it difficult 681 for hosting providers to set CAA policies on their own FQDNs without 682 setting potentially unwanted CAA policies on their customers' FQDNs. 683 This document specifies a simplified processing algorithm that only 684 performs tree climbing on the FQDN being processed, and leaves 685 processing of CNAMEs and DNAMEs up to the CA's recursive resolver. 687 This document also includes a "Deployment Considerations" section 688 detailing experience gained with practical deployment of CAA 689 enforcement among CAs in the WebPKI. 691 This document clarifies the ABNF grammar for the issue and issuewild 692 tags and resolves some inconsistencies with the document text. In 693 particular, it specifies that parameters are separated with 694 semicolons. It also allows hyphens in Property Tags. 696 This document also clarifies processing of a CAA RRset that is not 697 empty, but contains no issue or issuewild tags. 699 This document removes the section titled "The CAA RR Type," merging 700 it with "Mechanism" because the definitions were mainly duplicates. 701 It moves the "Use of DNS Security" section into Security 702 Considerations. It renames "Certification Authority Processing" to 703 "Relevant Resource Record Set," and emphasizes the use of that term 704 to more clearly define which domains are affected by a given RRset. 706 8. IANA Considerations 708 IANA is requested to add [[[ RFC Editor: Please replace with this RFC 709 ]]] as a reference for the Certification Authority Restriction Flags 710 and Certification Authority Restriction Properties registries, and 711 update references to [RFC6844] within those registries to refer to 712 [[[ RFC Editor: Please replace with this RFC ]]]. IANA is also 713 requested to update the CAA TYPE in the DNS Parameters registry with 714 a reference to [[[ RFC Editor: Please replace with this RFC ]]]. 716 9. Acknowledgements 718 The authors would like to thank the following people who contributed 719 to the design and documentation of this work item: Corey Bonnell, 720 Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim 721 Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger, 722 Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson. 724 10. References 726 10.1. Normative References 728 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 729 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 730 . 732 [RFC1035] Mockapetris, P., "Domain names - implementation and 733 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 734 November 1987, . 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 742 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 743 . 745 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 746 Rose, "DNS Security Introduction and Requirements", 747 RFC 4033, DOI 10.17487/RFC4033, March 2005, 748 . 750 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 751 Rose, "Resource Records for the DNS Security Extensions", 752 RFC 4034, DOI 10.17487/RFC4034, March 2005, 753 . 755 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 756 Rose, "Protocol Modifications for the DNS Security 757 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 758 . 760 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 761 Security (DNSSEC) Hashed Authenticated Denial of 762 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 763 . 765 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 766 Specifications: ABNF", STD 68, RFC 5234, 767 DOI 10.17487/RFC5234, January 2008, 768 . 770 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 771 Housley, R., and W. Polk, "Internet X.509 Public Key 772 Infrastructure Certificate and Certificate Revocation List 773 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 774 . 776 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 777 Defense (RID) Messages over HTTP/TLS", RFC 6546, 778 DOI 10.17487/RFC6546, April 2012, 779 . 781 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 782 of Named Entities (DANE) Transport Layer Security (TLS) 783 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 784 2012, . 786 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 787 Authority Authorization (CAA) Resource Record", RFC 6844, 788 DOI 10.17487/RFC6844, January 2013, 789 . 791 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 792 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 793 November 2016, . 795 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 796 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 797 May 2017, . 799 10.2. Informative References 801 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 802 Wu, "Internet X.509 Public Key Infrastructure Certificate 803 Policy and Certification Practices Framework", RFC 3647, 804 DOI 10.17487/RFC3647, November 2003, 805 . 807 Authors' Addresses 809 Phillip Hallam-Baker 811 Email: phill@hallambaker.com 812 Rob Stradling 813 Sectigo Ltd. 815 Email: rob@sectigo.com 817 Jacob Hoffman-Andrews 818 Let's Encrypt 820 Email: jsha@letsencrypt.org