idnits 2.17.1 draft-ietf-lamps-rfc6844bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 06, 2018) is 1998 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: 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 Comodo Group, Inc 4 Obsoletes: 6844 (if approved) R. Stradling 5 Intended status: Standards Track Sectigo 6 Expires: May 10, 2019 J. Hoffman-Andrews 7 Let's Encrypt 8 November 06, 2018 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-ietf-lamps-rfc6844bis-03 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 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 May 10, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . 4 62 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 63 3. The CAA RR Type . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Certification Authority Processing . . . . . . . . . . . . . 7 65 4.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8 66 5. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.1.1. Canonical Presentation Format . . . . . . . . . . . . 10 69 5.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 10 70 5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12 71 5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 6.1. Non-Compliance by Certification Authority . . . . . . . . 13 74 6.2. Mis-Issue by Authorized Certification Authority . . . . . 13 75 6.3. Suppression or Spoofing of CAA Records . . . . . . . . . 14 76 6.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 77 6.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . 14 78 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 79 7.1. Blocked Queries or Responses . . . . . . . . . . . . . . 15 80 7.2. Rejected Queries and Malformed Responses . . . . . . . . 15 81 7.3. Delegation to Private Nameservers . . . . . . . . . . . . 15 82 7.4. Bogus DNSSEC Responses . . . . . . . . . . . . . . . . . 15 83 8. Differences versus RFC6844 . . . . . . . . . . . . . . . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 9.1. Certification Authority Restriction Flags . . . . . . . . 16 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 11.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 The Certification Authority Authorization (CAA) DNS Resource Record 95 allows a DNS domain name holder to specify the Certification 96 Authorities (CAs) authorized to issue certificates for that domain. 98 Publication of CAA Resource Records allows a public Certification 99 Authority to implement additional controls to reduce the risk of 100 unintended certificate mis-issue. 102 Like the TLSA record defined in DNS-Based Authentication of Named 103 Entities (DANE) [RFC6698], CAA records are used as a part of a 104 mechanism for checking PKIX certificate data. The distinction 105 between the two specifications is that CAA records specify an 106 authorization control to be performed by a certificate issuer before 107 issue of a certificate and TLSA records specify a verification 108 control to be performed by a relying party after the certificate is 109 issued. 111 Conformance with a published CAA record is a necessary but not 112 sufficient condition for issuance of a certificate. Before issuing a 113 certificate, a PKIX CA is required to validate the request according 114 to the policies set out in its Certificate Policy. In the case of a 115 public CA that validates certificate requests as a third party, the 116 certificate will typically be issued under a public trust anchor 117 certificate embedded in one or more relevant Relying Applications. 119 Criteria for inclusion of embedded trust anchor certificates in 120 applications are outside the scope of this document. Typically, such 121 criteria require the CA to publish a Certification Practices 122 Statement (CPS) that specifies how the requirements of the 123 Certificate Policy (CP) are achieved. It is also common for a CA to 124 engage an independent third-party auditor to prepare an annual audit 125 statement of its performance against its CPS. 127 A set of CAA records describes only current grants of authority to 128 issue certificates for the corresponding DNS domain. Since a 129 certificate is typically valid for at least a year, it is possible 130 that a certificate that is not conformant with the CAA records 131 currently published was conformant with the CAA records published at 132 the time that the certificate was issued. Relying Applications MUST 133 NOT use CAA records as part of certificate validation. 135 CAA records MAY be used by Certificate Evaluators as a possible 136 indicator of a security policy violation. Such use SHOULD take 137 account of the possibility that published CAA records changed between 138 the time a certificate was issued and the time at which the 139 certificate was observed by the Certificate Evaluator. 141 2. Definitions 142 2.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2.2. Defined Terms 150 The following terms are used in this document: 152 Authorization Entry: An authorization assertion that grants or denies 153 a specific set of permissions to a specific group of entities. 155 Certificate: An X.509 Certificate, as specified in [RFC5280]. 157 Certificate Evaluator: A party other than a relying party that 158 evaluates the trustworthiness of certificates issued by Certification 159 Authorities. 161 Certification Authority (CA): An issuer that issues certificates in 162 accordance with a specified Certificate Policy. 164 Certificate Policy (CP): Specifies the criteria that a Certification 165 Authority undertakes to meet in its issue of certificates. See 166 [RFC3647]. 168 Certification Practices Statement (CPS): Specifies the means by which 169 the criteria of the Certificate Policy are met. In most cases, this 170 will be the document against which the operations of the 171 Certification Authority are audited. See [RFC3647]. 173 Domain: A DNS Domain Name. 175 Domain Name: A DNS Domain Name as specified in [RFC1034]. 177 Domain Name System (DNS): The Internet naming system specified in 178 [RFC1034] and [RFC1035]. 180 DNS Security (DNSSEC): Extensions to the DNS that provide 181 authentication services as specified in [RFC4033], [RFC4034], 182 [RFC4035], [RFC5155], and revisions. 184 Issuer: An entity that issues certificates. See [RFC5280]. 186 Property: The tag-value portion of a CAA Resource Record. 188 Property Tag: The tag portion of a CAA Resource Record. 190 Property Value: The value portion of a CAA Resource Record. 192 Public Key Infrastructure X.509 (PKIX): Standards and specifications 193 issued by the IETF that apply the X.509 certificate standards 194 specified by the ITU to Internet applications as specified in 195 [RFC5280] and related documents. 197 Resource Record (RR): A particular entry in the DNS including the 198 owner name, class, type, time to live, and data, as defined in 199 [RFC1034] and [RFC2181]. 201 Resource Record Set (RRSet): A set of Resource Records of a 202 particular owner name, class, and type. The time to live on all RRs 203 with an RRSet is always the same, but the data may be different among 204 RRs in the RRSet. 206 Relying Party: A party that makes use of an application whose 207 operation depends on use of a certificate for making a security 208 decision. See [RFC5280]. 210 Relying Application: An application whose operation depends on use of 211 a certificate for making a security decision. 213 3. The CAA RR Type 215 A CAA RR consists of a flags byte and a tag-value pair referred to as 216 a property. Multiple properties MAY be associated with the same 217 domain name by publishing multiple CAA RRs at that domain name. The 218 following flag is defined: 220 Issuer Critical: If set to '1', indicates that the corresponding 221 property tag MUST be understood if the semantics of the CAA record 222 are to be correctly interpreted by an issuer. 224 Issuers MUST NOT issue certificates for a domain if the relevant CAA 225 Resource Record set contains unknown property tags that have the 226 Critical bit set. 228 The following property tags are defined: 230 issue [; = ]* : The issue property 231 entry authorizes the holder of the domain name 232 or a party acting under the explicit authority of the holder of that 233 domain name to issue certificates for the domain in which the 234 property is published. 236 issuewild [; = ]* : The issuewild 237 property entry authorizes the holder of the domain name or a party acting under the explicit authority of the 239 holder of that domain name to issue wildcard certificates for the 240 domain in which the property is published. 242 iodef : Specifies a URL to which an issuer MAY report 243 certificate issue requests that are inconsistent with the issuer's 244 Certification Practices or Certificate Policy, or that a Certificate 245 Evaluator may use to report observation of a possible policy 246 violation. The Incident Object Description Exchange Format (IODEF) 247 format is used [RFC7970]. 249 The following example is a DNS zone file (see [RFC1035]) that informs 250 CAs that certificates are not to be issued except by the holder of 251 the domain name 'ca.example.net' or an authorized agent thereof. 252 This policy applies to all subordinate domains under example.com. 254 $ORIGIN example.com 255 . CAA 0 issue "ca.example.net" 257 If the domain name holder specifies one or more iodef properties, a 258 certificate issuer MAY report invalid certificate requests to that 259 address. In the following example, the domain name holder specifies 260 that reports may be made by means of email with the IODEF data as an 261 attachment, a Web service [RFC6546], or both: 263 $ORIGIN example.com 264 . CAA 0 issue "ca.example.net" 265 . CAA 0 iodef "mailto:security@example.com" 266 . CAA 0 iodef "http://iodef.example.com/" 268 A certificate issuer MAY specify additional parameters that allow 269 customers to specify additional parameters governing certificate 270 issuance. This might be the Certificate Policy under which the 271 certificate is to be issued, the authentication process to be used 272 might be specified, or an account number specified by the CA to 273 enable these parameters to be retrieved. 275 For example, the CA 'ca.example.net' has requested its customer 276 'example.com' to specify the CA's account number '230123' in each of 277 the customer's CAA records. 279 $ORIGIN example.com 280 . CAA 0 issue "ca.example.net; account=230123" 282 The syntax of additional parameters is a sequence of name-value pairs 283 as defined in Section 5.2. The semantics of such parameters is left 284 to site policy and is outside the scope of this document. 286 The critical flag is intended to permit future versions of CAA to 287 introduce new semantics that MUST be understood for correct 288 processing of the record, preventing conforming CAs that do not 289 recognize the new semantics from issuing certificates for the 290 indicated domains. 292 In the following example, the property 'tbs' is flagged as critical. 293 Neither the example.net CA nor any other issuer is authorized to 294 issue under either policy unless the processing rules for the 'tbs' 295 property tag are understood. 297 $ORIGIN example.com 298 . CAA 0 issue "ca.example.net; policy=ev" 299 . CAA 128 tbs "Unknown" 301 Note that the above restrictions only apply at certificate issue. 302 Since the validity of an end entity certificate is typically a year 303 or more, it is quite possible that the CAA records published at a 304 domain will change between the time a certificate was issued and 305 validation by a relying party. 307 4. Certification Authority Processing 309 Before issuing a certificate, a compliant CA MUST check for 310 publication of a relevant CAA Resource Record set. If such a record 311 set exists, a CA MUST NOT issue a certificate unless the CA 312 determines that either (1) the certificate request is consistent with 313 the applicable CAA Resource Record set or (2) an exception specified 314 in the relevant Certificate Policy or Certification Practices 315 Statement applies. 317 A certificate request MAY specify more than one domain name and MAY 318 specify wildcard domains. Issuers MUST verify authorization for all 319 the domains and wildcard domains specified in the request. 321 The search for a CAA Resource Record set climbs the DNS name tree 322 from the specified label up to but not including the DNS root '.' 323 until a CAA Resource Record set is found. 325 Given a request for a specific domain name X, or a request for a 326 wildcard domain name *.X, the relevant record set RelevantCAASet(X) 327 is determined as follows: 329 Let CAA(X) be the record set returned by performing a CAA record 330 query for the domain name X, according to the lookup algorithm 331 specified in RFC 1034 section 4.3.2 (in particular chasing aliases). 332 Let Parent(X) be the domain name produced by removing the leftmost 333 label of X. 335 RelevantCAASet(domain): 336 for domain is not ".": 337 if CAA(domain) is not Empty: 338 return CAA(domain) 339 domain = Parent(domain) 340 return Empty 342 For example, processing CAA for the domain name "X.Y.Z" where there 343 are no CAA records at any level in the tree RelevantCAASet would have 344 the following steps: 346 CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z." 347 CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z." 348 CAA("Z.") = Empty; domain = Parent("Z.") = "." 349 return Empty 351 Processing CAA for the domain name "A.B.C" where there is a CAA 352 record "issue example.com" at "B.C" would terminate early upon 353 finding the CAA record: 355 CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C." 356 CAA("B.C.") = "issue example.com" 357 return "issue example.com" 359 4.1. Use of DNS Security 361 Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not 362 required. An issuer MUST NOT issue certificates if doing so would 363 conflict with the relevant CAA Resource Record set, irrespective of 364 whether the corresponding DNS records are signed. 366 DNSSEC provides a proof of non-existence for both DNS domains and RR 367 set within domains. DNSSEC verification thus enables an issuer to 368 determine if the answer to a CAA record query is empty because the RR 369 set is empty or if it is non-empty but the response has been 370 suppressed. 372 Use of DNSSEC allows an issuer to acquire and archive a proof that 373 they were authorized to issue certificates for the domain. 374 Verification of such archives MAY be an audit requirement to verify 375 CAA record processing compliance. Publication of such archives MAY 376 be a transparency requirement to verify CAA record processing 377 compliance. 379 5. Mechanism 381 5.1. Syntax 383 A CAA RR contains a single property entry consisting of a tag-value 384 pair. Each tag represents a property of the CAA record. The value 385 of a CAA property is that specified in the corresponding value field. 387 A domain name MAY have multiple CAA RRs associated with it and a 388 given property MAY be specified more than once. 390 The CAA data field contains one property entry. A property entry 391 consists of the following data fields: 393 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 394 | Flags | Tag Length = n | 395 +----------------|----------------+...+---------------+ 396 | Tag char 0 | Tag char 1 |...| Tag char n-1 | 397 +----------------|----------------+...+---------------+ 398 +----------------|----------------+.....+----------------+ 399 | Value byte 0 | Value byte 1 |.....| Value byte m-1 | 400 +----------------|----------------+.....+----------------+ 402 Where n is the length specified in the Tag length field and m is the 403 remaining octets in the Value field (m = d - n - 2) where d is the 404 length of the RDATA section. 406 The data fields are defined as follows: 408 Flags: One octet containing the following field: 410 Bit 0, Issuer Critical Flag: If the value is set to '1', the critical 411 flag is asserted and the property MUST be understood if the CAA 412 record is to be correctly processed by a certificate issuer. 414 A Certification Authority MUST NOT issue certificates for any Domain 415 that contains a CAA critical property for an unknown or unsupported 416 property tag that for which the issuer critical flag is set. 418 Note that according to the conventions set out in [RFC1035], bit 0 is 419 the Most Significant Bit and bit 7 is the Least Significant Bit. 420 Thus, the Flags value 1 means that bit 7 is set while a value of 128 421 means that bit 0 is set according to this convention. 423 All other bit positions are reserved for future use. 425 To ensure compatibility with future extensions to CAA, DNS records 426 compliant with this version of the CAA specification MUST clear (set 427 to "0") all reserved flags bits. Applications that interpret CAA 428 records MUST ignore the value of all reserved flag bits. 430 Tag Length: A single octet containing an unsigned integer specifying 431 the tag length in octets. The tag length MUST be at least 1 and 432 SHOULD be no more than 15. 434 Tag: The property identifier, a sequence of US-ASCII characters. 436 Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' 437 through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT 438 contain any other characters. Matching of tag values is case 439 insensitive. 441 Tag values submitted for registration by IANA MUST NOT contain any 442 characters other than the (lowercase) US-ASCII characters 'a' through 443 'z' and the numbers 0 through 9. 445 Value: A sequence of octets representing the property value. 446 Property values are encoded as binary values and MAY employ sub- 447 formats. 449 The length of the value field is specified implicitly as the 450 remaining length of the enclosing Resource Record data field. 452 5.1.1. Canonical Presentation Format 454 The canonical presentation format of the CAA record is: 456 CAA 458 Where: 460 Flags: Is an unsigned integer between 0 and 255. 462 Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower 463 case. 465 Value: Is the encoding of the value field as 466 specified in [RFC1035], Section 5.1. 468 5.2. CAA issue Property 470 The issue property tag is used to request that certificate issuers 471 perform CAA issue restriction processing for the domain and to grant 472 authorization to specific certificate issuers. 474 The CAA issue property value has the following sub-syntax (specified 475 in ABNF as per [RFC5234]). 477 issuevalue = *WSP [domain *WSP] [";" *WSP [parameters *WSP]] 479 domain = label *("." label) 480 label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 482 parameters = (parameter *WSP ";" *WSP parameters) / parameter 483 parameter = tag *WSP "=" *WSP value 484 tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 485 value = *(%x21-3A / %x3C-7E) 487 For consistency with other aspects of DNS administration, domain name 488 values are specified in letter-digit-hyphen Label (LDH-Label) form. 490 A CAA record with an issue parameter tag that does not specify a 491 domain name is a request that certificate issuers perform CAA issue 492 restriction processing for the corresponding domain without granting 493 authorization to any certificate issuer. 495 This form of issue restriction would be appropriate to specify that 496 no certificates are to be issued for the domain in question. 498 For example, the following CAA resource record set requests that no 499 certificates be issued for the domain 'nocerts.example.com' by any 500 certificate issuer. 502 nocerts.example.com CAA 0 issue ";" 504 A CAA record with an issue parameter tag that specifies a domain name 505 is a request that certificate issuers perform CAA issue restriction 506 processing for the corresponding domain and grants authorization to 507 the certificate issuer specified by the domain name. 509 For example, the following CAA record set requests that no 510 certificates be issued for the domain 'certs.example.com' by any 511 certificate issuer other than the example.net certificate issuer. 513 certs.example.com CAA 0 issue "example.net" 515 CAA authorizations are additive; thus, the result of specifying both 516 the empty issuer and a specified issuer is the same as specifying 517 just the specified issuer alone. 519 An issue property tag where the issuevalue does not match the ABNF 520 grammar MUST be treated the same as one specifying the empty issuer. 522 For example, the following malformed CAA resource record set forbids 523 issuance: 525 malformed.example.com CAA 0 issue "%%%%%" 527 A non-empty CAA record set that contains no issue property tags is 528 authorization to any certificate issuer to issue for the 529 corresponding domain, provided that it is a non-wildcard domain, and 530 no records in the CAA record set otherwise prohibit issuance. 532 An issuer MAY choose to specify issuer-parameters that further 533 constrain the issue of certificates by that issuer, for example, 534 specifying that certificates are to be subject to specific validation 535 polices, billed to certain accounts, or issued under specific trust 536 anchors. 538 The semantics of issuer-parameters are determined by the issuer 539 alone. 541 5.3. CAA issuewild Property 543 The issuewild property has the same syntax and semantics as the issue 544 property except that issuewild properties only grant authorization to 545 issue certificates that specify a wildcard domain and issuewild 546 properties take precedence over issue properties when specified. 547 Specifically: 549 issuewild properties MUST be ignored when processing a request for a 550 domain that is not a wildcard domain. 552 If at least one issuewild property is specified in the relevant CAA 553 record set, all issue properties MUST be ignored when processing a 554 request for a domain that is a wildcard domain. 556 A non-empty CAA record set that contains no issue or issuewild 557 property tags is authorization to any certificate issuer to issue for 558 the corresponding wildcard domain, provided that no records in the 559 CAA record set otherwise prohibit issuance. 561 5.4. CAA iodef Property 563 The iodef property specifies a means of reporting certificate issue 564 requests or cases of certificate issue for the corresponding domain 565 that violate the security policy of the issuer or the domain name 566 holder. 568 The Incident Object Description Exchange Format (IODEF) [RFC7970] is 569 used to present the incident report in machine-readable form. 571 The iodef property takes a URL as its parameter. The URL scheme type 572 determines the method used for reporting: 574 mailto: The IODEF incident report is reported as a MIME email 575 attachment to an SMTP email that is submitted to the mail address 576 specified. The mail message sent SHOULD contain a brief text message 577 to alert the recipient to the nature of the attachment. 579 http or https: The IODEF report is submitted as a Web service request 580 to the HTTP address specified using the protocol specified in 581 [RFC6546]. 583 6. Security Considerations 585 CAA records assert a security policy that the holder of a domain name 586 wishes to be observed by certificate issuers. The effectiveness of 587 CAA records as an access control mechanism is thus dependent on 588 observance of CAA constraints by issuers. 590 The objective of the CAA record properties described in this document 591 is to reduce the risk of certificate mis-issue rather than avoid 592 reliance on a certificate that has been mis-issued. DANE [RFC6698] 593 describes a mechanism for avoiding reliance on mis-issued 594 certificates. 596 6.1. Non-Compliance by Certification Authority 598 CAA records offer CAs a cost-effective means of mitigating the risk 599 of certificate mis-issue: the cost of implementing CAA checks is very 600 small and the potential costs of a mis-issue event include the 601 removal of an embedded trust anchor. 603 6.2. Mis-Issue by Authorized Certification Authority 605 Use of CAA records does not prevent mis-issue by an authorized 606 Certification Authority, i.e., a CA that is authorized to issue 607 certificates for the domain in question by CAA records. 609 Domain name holders SHOULD verify that the CAs they authorize to 610 issue certificates for their domains employ appropriate controls to 611 ensure that certificates are issued only to authorized parties within 612 their organization. 614 Such controls are most appropriately determined by the domain name 615 holder and the authorized CA(s) directly and are thus out of scope of 616 this document. 618 6.3. Suppression or Spoofing of CAA Records 620 Suppression of the CAA record or insertion of a bogus CAA record 621 could enable an attacker to obtain a certificate from an issuer that 622 was not authorized to issue for that domain name. 624 Where possible, issuers SHOULD perform DNSSEC validation to detect 625 missing or modified CAA record sets. 627 In cases where DNSSEC is not deployed in a corresponding domain, an 628 issuer SHOULD attempt to mitigate this risk by employing appropriate 629 DNS security controls. For example, all portions of the DNS lookup 630 process SHOULD be performed against the authoritative name server. 631 Data cached by third parties MUST NOT be relied on but MAY be used to 632 support additional anti-spoofing or anti-suppression controls. 634 6.4. Denial of Service 636 Introduction of a malformed or malicious CAA RR could in theory 637 enable a Denial-of-Service (DoS) attack. 639 This specific threat is not considered to add significantly to the 640 risk of running an insecure DNS service. 642 An attacker could, in principle, perform a DoS attack against an 643 issuer by requesting a certificate with a maliciously long DNS name. 644 In practice, the DNS protocol imposes a maximum name length and CAA 645 processing does not exacerbate the existing need to mitigate DoS 646 attacks to any meaningful degree. 648 6.5. Abuse of the Critical Flag 650 A Certification Authority could make use of the critical flag to 651 trick customers into publishing records that prevent competing 652 Certification Authorities from issuing certificates even though the 653 customer intends to authorize multiple providers. 655 In practice, such an attack would be of minimal effect since any 656 competent competitor that found itself unable to issue certificates 657 due to lack of support for a property marked critical SHOULD 658 investigate the cause and report the reason to the customer. The 659 customer will thus discover that they had been deceived. 661 7. Deployment Considerations 662 7.1. Blocked Queries or Responses 664 Some middleboxes, in particular anti-DDoS appliances, may be 665 configured to drop DNS packets of unknown types, or may start 666 dropping such packets when they consider themselves under attack. 667 This generally manifests as a timed-out DNS query, or a SERVFAIL at a 668 local recursive resolver. 670 For deployability of CAA and future DNS record types, middleboxes 671 SHOULD block DNS packets by volume and size rather than by query 672 type. 674 7.2. Rejected Queries and Malformed Responses 676 Some authoritative nameservers respond with REJECTED or NOTIMP when 677 queried for a resource record type they do not recognize. At least 678 one authoritative resolver produces a malformed response (with the QR 679 bit set to 0) when queried for unknown resource record types. Per 680 RFC 1034, the correct response for unknown resource record types is 681 NOERROR. 683 7.3. Delegation to Private Nameservers 685 Some domain administrators make the contents of a subdomain 686 unresolvable on the public internet by delegating that subdomain to a 687 nameserver whose IP address is private. A CA processing CAA records 688 for such subdomains will receive SERVFAIL from its recursive 689 resolver. The CA MAY interpret that as preventing issuance. Domain 690 administrators wishing to issue certificates for private domains 691 SHOULD use split-horizon DNS with a publicly available nameserver, so 692 that CAs can receive a valid, empty CAA response for those domains. 694 7.4. Bogus DNSSEC Responses 696 Queries for CAA resource records are different from most DNS RR 697 types, because a signed, empty response to a query for CAA RRs is 698 meaningfully different from a bogus response. A signed, empty 699 response indicates that there is definitely no CAA policy set at a 700 given label. A bogus response may mean either a misconfigured zone, 701 or an attacker tampering with records. DNSSEC implementations may 702 have bugs with signatures on empty responses that go unnoticed, 703 because for more common resource record types like A and AAAA, the 704 difference to an end user between empty and bogus is irrelevant; they 705 both mean a site is unavailable. 707 In particular, at least two authoritative resolvers that implement 708 live signing had bugs when returning empty resource record sets for 709 DNSSEC-signed zones, in combination with mixed-case queries. Mixed- 710 case queries, also known as DNS 0x20, are used by some recursive 711 resolvers to increase resilience against DNS poisoning attacks. 712 DNSSEC-signing authoritative resolvers are expected to copy the same 713 capitalization from the query into their ANSWER section, but sign the 714 response as if they had use all lowercase. In particular, PowerDNS 715 versions prior to 4.0.4 had this bug. 717 8. Differences versus RFC6844 719 This document obsoletes RFC6844. The most important change is to the 720 Certification Authority Processing section. RFC6844 specified an 721 algorithm that performed DNS tree-climbing not only on the domain 722 name being processed, but also on all CNAMEs and DNAMEs encountered 723 along the way. This made the processing algorithm very inefficient 724 when used on domains that utilize many CNAMEs, and would have made it 725 difficult for hosting providers to set CAA policies on their own 726 domains without setting potentially unwanted CAA policies on their 727 customers' domains. This document specifies a simplified processing 728 algorithm that only performs tree climbing on the domain being 729 processed, and leaves processing of CNAMEs and DNAMEs up to the CA's 730 recursive resolver. 732 This document also includes a "Deployment Considerations" section 733 detailing experience gained with practical deployment of CAA 734 enforcement among CAs in the WebPKI. 736 This document clarifies the ABNF grammar for issue and issuewild tags 737 and resolves some inconsistencies with the document text. In 738 particular, it specifies that parameters are separated with hyphens. 739 It also allows hyphens in property names. 741 This document also clarifies processing of a CAA RRset that is not 742 empty, but contains no issue or issuewild tags. 744 9. IANA Considerations 746 This document has no IANA actions. 748 9.1. Certification Authority Restriction Flags 750 IANA has created the "Certification Authority Restriction Flags" 751 registry with the following initial values: 753 +------+----------------------+-----------+ 754 | Flag | Meaning | Reference | 755 +------+----------------------+-----------+ 756 | 0 | Issuer Critical Flag | [RFC6844] | 757 | | | | 758 | 1-7 | Reserved> | [RFC6844] | 759 +------+----------------------+-----------+ 761 Assignment of new flags follows the RFC Required policy set out in 762 [RFC8126], Section 4.1. 764 10. Acknowledgements 766 The authors would like to thank the following people who contributed 767 to the design and documentation of this work item: Chris Evans, 768 Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam 769 Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean 770 Turner, and Ben Wilson. 772 11. References 774 11.1. Normative References 776 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 777 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 778 . 780 [RFC1035] Mockapetris, P., "Domain names - implementation and 781 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 782 November 1987, . 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, 786 DOI 10.17487/RFC2119, March 1997, 787 . 789 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 790 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 791 . 793 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 794 Rose, "DNS Security Introduction and Requirements", 795 RFC 4033, DOI 10.17487/RFC4033, March 2005, 796 . 798 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 799 Rose, "Resource Records for the DNS Security Extensions", 800 RFC 4034, DOI 10.17487/RFC4034, March 2005, 801 . 803 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 804 Rose, "Protocol Modifications for the DNS Security 805 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 806 . 808 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 809 Security (DNSSEC) Hashed Authenticated Denial of 810 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 811 . 813 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 814 Specifications: ABNF", STD 68, RFC 5234, 815 DOI 10.17487/RFC5234, January 2008, 816 . 818 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 819 Housley, R., and W. Polk, "Internet X.509 Public Key 820 Infrastructure Certificate and Certificate Revocation List 821 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 822 . 824 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 825 Defense (RID) Messages over HTTP/TLS", RFC 6546, 826 DOI 10.17487/RFC6546, April 2012, 827 . 829 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 830 of Named Entities (DANE) Transport Layer Security (TLS) 831 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 832 2012, . 834 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 835 Authority Authorization (CAA) Resource Record", RFC 6844, 836 DOI 10.17487/RFC6844, January 2013, 837 . 839 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 840 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 841 November 2016, . 843 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 844 Writing an IANA Considerations Section in RFCs", BCP 26, 845 RFC 8126, DOI 10.17487/RFC8126, June 2017, 846 . 848 11.2. Informative References 850 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 851 Wu, "Internet X.509 Public Key Infrastructure Certificate 852 Policy and Certification Practices Framework", RFC 3647, 853 DOI 10.17487/RFC3647, November 2003, 854 . 856 Authors' Addresses 858 Phillip Hallam-Baker 859 Comodo Group, Inc 861 Email: philliph@comodo.com 863 Rob Stradling 864 Sectigo Ltd. 866 Email: rob@sectigo.com 868 Jacob Hoffman-Andrews 869 Let's Encrypt 871 Email: jsha@letsencrypt.org