idnits 2.17.1 draft-ietf-lamps-rfc6844bis-04.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 (December 03, 2018) is 1968 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: 0 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 Comodo Group, Inc 4 Obsoletes: 6844 (if approved) R. Stradling 5 Intended status: Standards Track Sectigo 6 Expires: June 6, 2019 J. Hoffman-Andrews 7 Let's Encrypt 8 December 03, 2018 10 DNS Certification Authority Authorization (CAA) Resource Record 11 draft-ietf-lamps-rfc6844bis-04 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 June 6, 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 . . . . . . . . . . . . . . . . . . . 11 70 5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12 71 5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 15 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 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 11.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 Publication of CAA Resource Records allows a public Certification 97 Authority to implement additional controls to reduce the risk of 98 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 certificate data. The distinction 103 between the two specifications is that CAA records specify an 104 authorization control to be performed by a certificate issuer before 105 issue of a certificate and TLSA records specify a verification 106 control to be performed by a relying party after the certificate is 107 issued. 109 Conformance with a published CAA record is a necessary but not 110 sufficient condition for issuance of a certificate. Before issuing a 111 certificate, a PKIX CA is required to validate the request according 112 to the policies set out in its Certificate Policy. In the case of a 113 public CA that validates certificate requests as a third party, the 114 certificate will typically be issued under a public trust anchor 115 certificate embedded in one or more relevant Relying Applications. 117 Criteria for inclusion of embedded trust anchor certificates in 118 applications are outside the scope of this document. Typically, such 119 criteria require the CA to publish a Certification Practices 120 Statement (CPS) that specifies how the requirements of the 121 Certificate Policy (CP) are achieved. It is also common for a CA to 122 engage an independent third-party auditor to prepare an annual audit 123 statement of its performance against its CPS. 125 A set of CAA records describes only current grants of authority to 126 issue certificates for the corresponding DNS domain. Since a 127 certificate is typically valid for at least a year, it is possible 128 that a certificate that is not conformant with the CAA records 129 currently published was conformant with the CAA records published at 130 the time that the certificate was issued. Relying Applications MUST 131 NOT use CAA records as part of certificate validation. 133 CAA records MAY be used by Certificate Evaluators as a possible 134 indicator of a security policy violation. Such use SHOULD take 135 account of the possibility that published CAA records changed between 136 the time a certificate was issued and the time at which the 137 certificate was observed by the Certificate Evaluator. 139 2. Definitions 140 2.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 2.2. Defined Terms 148 The following terms are used in this document: 150 Authorization Entry: An authorization assertion that grants or denies 151 a specific set of permissions to a specific group of entities. 153 Certificate: An X.509 Certificate, as specified in [RFC5280]. 155 Certificate Evaluator: A party other than a relying party that 156 evaluates the trustworthiness of certificates issued by Certification 157 Authorities. 159 Certification Authority (CA): An issuer that issues certificates in 160 accordance with a specified Certificate Policy. 162 Certificate Policy (CP): Specifies the criteria that a Certification 163 Authority undertakes to meet in its issue of certificates. See 164 [RFC3647]. 166 Certification Practices Statement (CPS): Specifies the means by which 167 the criteria of the Certificate Policy are met. In most cases, this 168 will be the document against which the operations of the 169 Certification Authority are audited. See [RFC3647]. 171 Domain: A DNS Domain Name. 173 Domain Name: A DNS Domain Name as specified in [RFC1034]. 175 Domain Name System (DNS): The Internet naming system specified in 176 [RFC1034] and [RFC1035]. 178 DNS Security (DNSSEC): Extensions to the DNS that provide 179 authentication services as specified in [RFC4033], [RFC4034], 180 [RFC4035], [RFC5155], and revisions. 182 Issuer: An entity that issues certificates. See [RFC5280]. 184 Property: The tag-value portion of a CAA Resource Record. 186 Property Tag: The tag portion of a CAA Resource Record. 188 Property Value: The value portion of a CAA Resource Record. 190 Public Key Infrastructure X.509 (PKIX): Standards and specifications 191 issued by the IETF that apply the X.509 certificate standards 192 specified by the ITU to Internet applications as specified in 193 [RFC5280] and related documents. 195 Resource Record (RR): A particular entry in the DNS including the 196 owner name, class, type, time to live, and data, as defined in 197 [RFC1034] and [RFC2181]. 199 Resource Record Set (RRSet): A set of Resource Records of a 200 particular owner name, class, and type. The time to live on all RRs 201 with an RRSet is always the same, but the data may be different among 202 RRs in the RRSet. 204 Relying Party: A party that makes use of an application whose 205 operation depends on use of a certificate for making a security 206 decision. See [RFC5280]. 208 Relying Application: An application whose operation depends on use of 209 a certificate for making a security decision. 211 3. The CAA RR Type 213 A CAA RR consists of a flags byte and a tag-value pair referred to as 214 a property. Multiple properties MAY be associated with the same 215 domain name by publishing multiple CAA RRs at that domain name. The 216 following flag is defined: 218 Issuer Critical: If set to '1', indicates that the corresponding 219 property tag MUST be understood if the semantics of the CAA record 220 are to be correctly interpreted by an issuer. 222 Issuers MUST NOT issue certificates for a domain if the relevant CAA 223 Resource Record set contains unknown property tags that have the 224 Critical bit set. 226 The following property tags are defined: 228 issue [; = ]* : The issue property 229 entry authorizes the holder of the domain name 230 or a party acting under the explicit authority of the holder of that 231 domain name to issue certificates for the domain in which the 232 property is published. 234 issuewild [; = ]* : The issuewild 235 property entry authorizes the holder of the domain name or a party acting under the explicit authority of the 237 holder of that domain name to issue wildcard certificates for the 238 domain in which the property is published. 240 iodef : Specifies a URL to which an issuer MAY report 241 certificate issue requests that are inconsistent with the issuer's 242 Certification Practices or Certificate Policy, or that a Certificate 243 Evaluator may use to report observation of a possible policy 244 violation. The Incident Object Description Exchange Format (IODEF) 245 format is used [RFC7970]. 247 The following example is a DNS zone file (see [RFC1035]) that informs 248 CAs that certificates are not to be issued except by the holder of 249 the domain name 'ca.example.net' or an authorized agent thereof. 250 This policy applies to all subordinate domains under example.com. 252 $ORIGIN example.com. 253 CAA 0 issue "ca.example.net" 255 If the domain name holder specifies one or more iodef properties, a 256 certificate issuer MAY report invalid certificate requests to that 257 address. In the following example, the domain name holder specifies 258 that reports may be made by means of email with the IODEF data as an 259 attachment, a Web service [RFC6546], or both: 261 $ORIGIN example.com. 262 CAA 0 issue "ca.example.net" 263 CAA 0 iodef "mailto:security@example.com" 264 CAA 0 iodef "http://iodef.example.com/" 266 A certificate issuer MAY specify additional parameters that allow 267 customers to specify additional parameters governing certificate 268 issuance. This might be the Certificate Policy under which the 269 certificate is to be issued, the authentication process to be used 270 might be specified, or an account number specified by the CA to 271 enable these parameters to be retrieved. 273 For example, the CA 'ca.example.net' has requested its customer 274 'example.com' to specify the CA's account number '230123' in each of 275 the customer's CAA records. 277 $ORIGIN example.com. 278 CAA 0 issue "ca.example.net; account=230123" 280 The syntax of additional parameters is a sequence of name-value pairs 281 as defined in Section 5.2. The semantics of such parameters is left 282 to site policy and is outside the scope of this document. 284 The critical flag is intended to permit future versions of CAA to 285 introduce new semantics that MUST be understood for correct 286 processing of the record, preventing conforming CAs that do not 287 recognize the new semantics from issuing certificates for the 288 indicated domains. 290 In the following example, the property 'tbs' is flagged as critical. 291 Neither the example.net CA nor any other issuer is authorized to 292 issue under either policy unless the processing rules for the 'tbs' 293 property tag are understood. 295 $ORIGIN example.com. 296 CAA 0 issue "ca.example.net; policy=ev" 297 CAA 128 tbs "Unknown" 299 Note that the above restrictions only apply at certificate issue. 300 Since the validity of an end entity certificate is typically a year 301 or more, it is quite possible that the CAA records published at a 302 domain will change between the time a certificate was issued and 303 validation by a relying party. 305 4. Certification Authority Processing 307 Before issuing a certificate, a compliant CA MUST check for 308 publication of a relevant CAA Resource Record set. If such a record 309 set exists, a CA MUST NOT issue a certificate unless the CA 310 determines that either (1) the certificate request is consistent with 311 the applicable CAA Resource Record set or (2) an exception specified 312 in the relevant Certificate Policy or Certification Practices 313 Statement applies. 315 A certificate request MAY specify more than one domain name and MAY 316 specify wildcard domains. Issuers MUST verify authorization for all 317 the domains and wildcard domains specified in the request. 319 The search for a CAA Resource Record set climbs the DNS name tree 320 from the specified label up to but not including the DNS root '.' 321 until a CAA Resource Record set is found. 323 Given a request for a specific domain name X, or a request for a 324 wildcard domain name *.X, the relevant record set RelevantCAASet(X) 325 is determined as follows: 327 Let CAA(X) be the record set returned by performing a CAA record 328 query for the domain name X, according to the lookup algorithm 329 specified in RFC 1034 section 4.3.2 (in particular chasing aliases). 330 Let Parent(X) be the domain name produced by removing the leftmost 331 label of X. 333 RelevantCAASet(domain): 334 for domain is not ".": 335 if CAA(domain) is not Empty: 336 return CAA(domain) 337 domain = Parent(domain) 338 return Empty 340 For example, processing CAA for the domain name "X.Y.Z" where there 341 are no CAA records at any level in the tree RelevantCAASet would have 342 the following steps: 344 CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z." 345 CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z." 346 CAA("Z.") = Empty; domain = Parent("Z.") = "." 347 return Empty 349 Processing CAA for the domain name "A.B.C" where there is a CAA 350 record "issue example.com" at "B.C" would terminate early upon 351 finding the CAA record: 353 CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C." 354 CAA("B.C.") = "issue example.com" 355 return "issue example.com" 357 4.1. Use of DNS Security 359 Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not 360 required. An issuer MUST NOT issue certificates if doing so would 361 conflict with the relevant CAA Resource Record set, irrespective of 362 whether the corresponding DNS records are signed. 364 DNSSEC provides a proof of non-existence for both DNS domains and RR 365 set within domains. DNSSEC verification thus enables an issuer to 366 determine if the answer to a CAA record query is empty because the RR 367 set is empty or if it is non-empty but the response has been 368 suppressed. 370 Use of DNSSEC allows an issuer to acquire and archive a proof that 371 they were authorized to issue certificates for the domain. 372 Verification of such archives MAY be an audit requirement to verify 373 CAA record processing compliance. Publication of such archives MAY 374 be a transparency requirement to verify CAA record processing 375 compliance. 377 5. Mechanism 379 5.1. Syntax 381 A CAA RR contains a single property entry consisting of a tag-value 382 pair. Each tag represents a property of the CAA record. The value 383 of a CAA property is that specified in the corresponding value field. 385 A domain name MAY have multiple CAA RRs associated with it and a 386 given property MAY be specified more than once. 388 The CAA data field contains one property entry. A property entry 389 consists of the following data fields: 391 +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| 392 | Flags | Tag Length = n | 393 +----------------|----------------+...+---------------+ 394 | Tag char 0 | Tag char 1 |...| Tag char n-1 | 395 +----------------|----------------+...+---------------+ 396 +----------------|----------------+.....+----------------+ 397 | Value byte 0 | Value byte 1 |.....| Value byte m-1 | 398 +----------------|----------------+.....+----------------+ 400 Where n is the length specified in the Tag length field and m is the 401 remaining octets in the Value field (m = d - n - 2) where d is the 402 length of the RDATA section. 404 The data fields are defined as follows: 406 Flags: One octet containing the following field: 408 Bit 0, Issuer Critical Flag: If the value is set to '1', the critical 409 flag is asserted and the property MUST be understood if the CAA 410 record is to be correctly processed by a certificate issuer. 412 A Certification Authority MUST NOT issue certificates for any Domain 413 that contains a CAA critical property for an unknown or unsupported 414 property tag that for which the issuer critical flag is set. 416 Note that according to the conventions set out in [RFC1035], bit 0 is 417 the Most Significant Bit and bit 7 is the Least Significant Bit. 418 Thus, the Flags value 1 means that bit 7 is set while a value of 128 419 means that bit 0 is set according to this convention. 421 All other bit positions are reserved for future use. 423 To ensure compatibility with future extensions to CAA, DNS records 424 compliant with this version of the CAA specification MUST clear (set 425 to "0") all reserved flags bits. Applications that interpret CAA 426 records MUST ignore the value of all reserved flag bits. 428 Tag Length: A single octet containing an unsigned integer specifying 429 the tag length in octets. The tag length MUST be at least 1 and 430 SHOULD be no more than 15. 432 Tag: The property identifier, a sequence of US-ASCII characters. 434 Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' 435 through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT 436 contain any other characters. Matching of tag values is case 437 insensitive. 439 Tag values submitted for registration by IANA MUST NOT contain any 440 characters other than the (lowercase) US-ASCII characters 'a' through 441 'z' and the numbers 0 through 9. 443 Value: A sequence of octets representing the property value. 444 Property values are encoded as binary values and MAY employ sub- 445 formats. 447 The length of the value field is specified implicitly as the 448 remaining length of the enclosing Resource Record data field. 450 5.1.1. Canonical Presentation Format 452 The canonical presentation format of the CAA record is: 454 CAA 456 Where: 458 Flags: Is an unsigned integer between 0 and 255. 460 Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower 461 case. 463 Value: The value field, expressed as a contiguous set of characters 464 without interior spaces, or as a quoted string. See the the 465 format specified in [RFC1035], Section 5.1, but 466 note that the value field contains no length byte and is not limited 467 to 255 characters. 469 5.2. CAA issue Property 471 The issue property tag is used to request that certificate issuers 472 perform CAA issue restriction processing for the domain and to grant 473 authorization to specific certificate issuers. 475 The CAA issue property value has the following sub-syntax (specified 476 in ABNF as per [RFC5234]). 478 issuevalue = *WSP [domain *WSP] [";" *WSP [parameters *WSP]] 480 domain = label *("." label) 481 label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 483 parameters = (parameter *WSP ";" *WSP parameters) / parameter 484 parameter = tag *WSP "=" *WSP value 485 tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 486 value = *(%x21-3A / %x3C-7E) 488 For consistency with other aspects of DNS administration, domain name 489 values are specified in letter-digit-hyphen Label (LDH-Label) form. 491 A CAA record with an issue parameter tag that does not specify a 492 domain name is a request that certificate issuers perform CAA issue 493 restriction processing for the corresponding domain without granting 494 authorization to any certificate issuer. 496 This form of issue restriction would be appropriate to specify that 497 no certificates are to be issued for the domain in question. 499 For example, the following CAA resource record set requests that no 500 certificates be issued for the domain 'nocerts.example.com' by any 501 certificate issuer. 503 nocerts.example.com CAA 0 issue ";" 505 A CAA record with an issue parameter tag that specifies a domain name 506 is a request that certificate issuers perform CAA issue restriction 507 processing for the corresponding domain and grants authorization to 508 the certificate issuer specified by the domain name. 510 For example, the following CAA record set requests that no 511 certificates be issued for the domain 'certs.example.com' by any 512 certificate issuer other than the example.net certificate issuer. 514 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. 521 For example, the following malformed CAA resource record set forbids 522 issuance: 524 malformed.example.com CAA 0 issue "%%%%%" 526 A non-empty CAA record set that contains no issue property tags is 527 authorization to any certificate issuer to issue for the 528 corresponding domain, provided that it is a non-wildcard domain, and 529 no records in the CAA record set otherwise prohibit issuance. 531 An issuer MAY choose to specify issuer-parameters that further 532 constrain the issue of certificates by that issuer, for example, 533 specifying that certificates are to be subject to specific validation 534 polices, billed to certain accounts, or issued under specific trust 535 anchors. 537 The semantics of issuer-parameters are determined by the issuer 538 alone. 540 5.3. CAA issuewild Property 542 The issuewild property has the same syntax and semantics as the issue 543 property except that issuewild properties only grant authorization to 544 issue certificates that specify a wildcard domain and issuewild 545 properties take precedence over issue properties when specified. 546 Specifically: 548 issuewild properties MUST be ignored when processing a request for a 549 domain that is not a wildcard domain. 551 If at least one issuewild property is specified in the relevant CAA 552 record set, all issue properties MUST be ignored when processing a 553 request for a domain that is a wildcard domain. 555 A non-empty CAA record set that contains no issue or issuewild 556 property tags is authorization to any certificate issuer to issue for 557 the corresponding wildcard domain, provided that no records in the 558 CAA record set otherwise prohibit issuance. 560 5.4. CAA iodef Property 562 The iodef property specifies a means of reporting certificate issue 563 requests or cases of certificate issue for the corresponding domain 564 that violate the security policy of the issuer or the domain name 565 holder. 567 The Incident Object Description Exchange Format (IODEF) [RFC7970] is 568 used to present the incident report in machine-readable form. 570 The iodef property takes a URL as its parameter. The URL scheme type 571 determines the method used for reporting: 573 mailto: The IODEF incident report is reported as a MIME email 574 attachment to an SMTP email that is submitted to the mail address 575 specified. The mail message sent SHOULD contain a brief text message 576 to alert the recipient to the nature of the attachment. 578 http or https: The IODEF report is submitted as a Web service request 579 to the HTTP address specified using the protocol specified in 580 [RFC6546]. 582 6. Security Considerations 584 CAA records assert a security policy that the holder of a domain name 585 wishes to be observed by certificate issuers. The effectiveness of 586 CAA records as an access control mechanism is thus dependent on 587 observance of CAA constraints by issuers. 589 The objective of the CAA record properties described in this document 590 is to reduce the risk of certificate mis-issue rather than avoid 591 reliance on a certificate that has been mis-issued. DANE [RFC6698] 592 describes a mechanism for avoiding reliance on mis-issued 593 certificates. 595 6.1. Non-Compliance by Certification Authority 597 CAA records offer CAs a cost-effective means of mitigating the risk 598 of certificate mis-issue: the cost of implementing CAA checks is very 599 small and the potential costs of a mis-issue event include the 600 removal of an embedded trust anchor. 602 6.2. Mis-Issue by Authorized Certification Authority 604 Use of CAA records does not prevent mis-issue by an authorized 605 Certification Authority, i.e., a CA that is authorized to issue 606 certificates for the domain in question by CAA records. 608 Domain name holders SHOULD verify that the CAs they authorize to 609 issue certificates for their domains employ appropriate controls to 610 ensure that certificates are issued only to authorized parties within 611 their organization. 613 Such controls are most appropriately determined by the domain name 614 holder and the authorized CA(s) directly and are thus out of scope of 615 this document. 617 6.3. Suppression or Spoofing of CAA Records 619 Suppression of the CAA record or insertion of a bogus CAA record 620 could enable an attacker to obtain a certificate from an issuer that 621 was not authorized to issue for that domain name. 623 Where possible, issuers SHOULD perform DNSSEC validation to detect 624 missing or modified CAA record sets. 626 In cases where DNSSEC is not deployed in a corresponding domain, an 627 issuer SHOULD attempt to mitigate this risk by employing appropriate 628 DNS security controls. For example, all portions of the DNS lookup 629 process SHOULD be performed against the authoritative name server. 630 Data cached by third parties MUST NOT be relied on but MAY be used to 631 support additional anti-spoofing or anti-suppression controls. 633 6.4. Denial of Service 635 Introduction of a malformed or malicious CAA RR could in theory 636 enable a Denial-of-Service (DoS) attack. 638 This specific threat is not considered to add significantly to the 639 risk of running an insecure DNS service. 641 An attacker could, in principle, perform a DoS attack against an 642 issuer by requesting a certificate with a maliciously long DNS name. 643 In practice, the DNS protocol imposes a maximum name length and CAA 644 processing does not exacerbate the existing need to mitigate DoS 645 attacks to any meaningful degree. 647 6.5. Abuse of the Critical Flag 649 A Certification Authority could make use of the critical flag to 650 trick customers into publishing records that prevent competing 651 Certification Authorities from issuing certificates even though the 652 customer intends to authorize multiple providers. 654 In practice, such an attack would be of minimal effect since any 655 competent competitor that found itself unable to issue certificates 656 due to lack of support for a property marked critical SHOULD 657 investigate the cause and report the reason to the customer. The 658 customer will thus discover that they had been deceived. 660 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 IANA is requested to add [[[ RFC Editor: Please replace with this RFC 747 ]]] as a reference for the Certification Authority Restriction Flags 748 and Certification Authority Restriction Properties registries. 750 10. Acknowledgements 752 The authors would like to thank the following people who contributed 753 to the design and documentation of this work item: Tim Hollebeek, 754 Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul 755 Hoffman, Stephen Kent, Adam Langley, Ben Laurie, James Manager, Chris 756 Palmer, Scott Schmit, Sean Turner, and Ben Wilson. 758 11. References 760 11.1. Normative References 762 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 763 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 764 . 766 [RFC1035] Mockapetris, P., "Domain names - implementation and 767 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 768 November 1987, . 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 776 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 777 . 779 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 780 Rose, "DNS Security Introduction and Requirements", 781 RFC 4033, DOI 10.17487/RFC4033, March 2005, 782 . 784 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 785 Rose, "Resource Records for the DNS Security Extensions", 786 RFC 4034, DOI 10.17487/RFC4034, March 2005, 787 . 789 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 790 Rose, "Protocol Modifications for the DNS Security 791 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 792 . 794 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 795 Security (DNSSEC) Hashed Authenticated Denial of 796 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 797 . 799 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 800 Specifications: ABNF", STD 68, RFC 5234, 801 DOI 10.17487/RFC5234, January 2008, 802 . 804 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 805 Housley, R., and W. Polk, "Internet X.509 Public Key 806 Infrastructure Certificate and Certificate Revocation List 807 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 808 . 810 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 811 Defense (RID) Messages over HTTP/TLS", RFC 6546, 812 DOI 10.17487/RFC6546, April 2012, 813 . 815 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 816 of Named Entities (DANE) Transport Layer Security (TLS) 817 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 818 2012, . 820 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 821 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 822 November 2016, . 824 11.2. Informative References 826 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 827 Wu, "Internet X.509 Public Key Infrastructure Certificate 828 Policy and Certification Practices Framework", RFC 3647, 829 DOI 10.17487/RFC3647, November 2003, 830 . 832 Authors' Addresses 834 Phillip Hallam-Baker 835 Comodo Group, Inc 837 Email: philliph@comodo.com 839 Rob Stradling 840 Sectigo Ltd. 842 Email: rob@sectigo.com 843 Jacob Hoffman-Andrews 844 Let's Encrypt 846 Email: jsha@letsencrypt.org