idnits 2.17.1 draft-ietf-lamps-rfc6844bis-02.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 04, 2018) is 1999 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 R. Stradling 4 Obsoletes: 6844 (if approved) Comodo Group, Inc 5 Intended status: Standards Track J. Hoffman-Andrews 6 Expires: May 8, 2019 Let's Encrypt 7 November 04, 2018 9 DNS Certification Authority Authorization (CAA) Resource Record 10 draft-ietf-lamps-rfc6844bis-02 12 Abstract 14 The Certification Authority Authorization (CAA) DNS Resource Record 15 allows a DNS domain name holder to specify one or more Certification 16 Authorities (CAs) authorized to issue certificates for that domain. 17 CAA Resource Records allow a public Certification Authority to 18 implement additional controls to reduce the risk of unintended 19 certificate mis-issue. This document defines the syntax of the CAA 20 record and rules for processing CAA records by certificate issuers. 22 This document obsoletes RFC 6844. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 8, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 62 3. The CAA RR Type . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Certification Authority Processing . . . . . . . . . . . . . 7 64 4.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 8 65 5. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1.1. Canonical Presentation Format . . . . . . . . . . . . 10 68 5.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 10 69 5.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 12 70 5.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6.1. Non-Compliance by Certification Authority . . . . . . . . 13 73 6.2. Mis-Issue by Authorized Certification Authority . . . . . 13 74 6.3. Suppression or Spoofing of CAA Records . . . . . . . . . 14 75 6.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 76 6.5. Abuse of the Critical Flag . . . . . . . . . . . . . . . 14 77 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 78 7.1. Blocked Queries or Responses . . . . . . . . . . . . . . 15 79 7.2. Rejected Queries and Malformed Responses . . . . . . . . 15 80 7.3. Delegation to Private Nameservers . . . . . . . . . . . . 15 81 7.4. Bogus DNSSEC Responses . . . . . . . . . . . . . . . . . 15 82 8. Differences versus RFC6844 . . . . . . . . . . . . . . . . . 16 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Certification Authority Restriction Flags . . . . . . . . 16 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 11.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 record climbs the DNS name tree from the 320 specified label up to but not including the DNS root '.' until CAA 321 records are 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: Is the encoding of the value field as 464 specified in [RFC1035], Section 5.1. 466 5.2. CAA issue Property 468 The issue property tag is used to request that certificate issuers 469 perform CAA issue restriction processing for the domain and to grant 470 authorization to specific certificate issuers. 472 The CAA issue property value has the following sub-syntax (specified 473 in ABNF as per [RFC5234]). 475 issuevalue = *WSP [domain *WSP] [";" *WSP [parameters *WSP]] 477 domain = label *("." label) 478 label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 480 parameters = (parameter *WSP ";" *WSP parameters) / parameter 481 parameter = tag *WSP "=" *WSP value 482 tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) 483 value = *(%x21-3A / %x3C-7E) 485 For consistency with other aspects of DNS administration, domain name 486 values are specified in letter-digit-hyphen Label (LDH-Label) form. 488 A CAA record with an issue parameter tag that does not specify a 489 domain name is a request that certificate issuers perform CAA issue 490 restriction processing for the corresponding domain without granting 491 authorization to any certificate issuer. 493 This form of issue restriction would be appropriate to specify that 494 no certificates are to be issued for the domain in question. 496 For example, the following CAA resource record set requests that no 497 certificates be issued for the domain 'nocerts.example.com' by any 498 certificate issuer. 500 nocerts.example.com CAA 0 issue ";" 502 A CAA record with an issue parameter tag that specifies a domain name 503 is a request that certificate issuers perform CAA issue restriction 504 processing for the corresponding domain and grants authorization to 505 the certificate issuer specified by the domain name. 507 For example, the following CAA record set requests that no 508 certificates be issued for the domain 'certs.example.com' by any 509 certificate issuer other than the example.net certificate issuer. 511 certs.example.com CAA 0 issue "example.net" 513 CAA authorizations are additive; thus, the result of specifying both 514 the empty issuer and a specified issuer is the same as specifying 515 just the specified issuer alone. 517 An issue property tag where the issuevalue does not match the ABNF 518 grammar MUST be treated the same as one specifying the empty issuer. 520 For example, the following malformed CAA resource record set forbids 521 issuance: 523 malformed.example.com CAA 0 issue "%%%%%" 525 A non-empty CAA record set that contains no issue property tags is 526 authorization to any certificate issuer to issue for the 527 corresponding domain, provided that it is a non-wildcard domain, and 528 no records in the CAA record set otherwise prohibit issuance. 530 An issuer MAY choose to specify issuer-parameters that further 531 constrain the issue of certificates by that issuer, for example, 532 specifying that certificates are to be subject to specific validation 533 polices, billed to certain accounts, or issued under specific trust 534 anchors. 536 The semantics of issuer-parameters are determined by the issuer 537 alone. 539 5.3. CAA issuewild Property 541 The issuewild property has the same syntax and semantics as the issue 542 property except that issuewild properties only grant authorization to 543 issue certificates that specify a wildcard domain and issuewild 544 properties take precedence over issue properties when specified. 545 Specifically: 547 issuewild properties MUST be ignored when processing a request for a 548 domain that is not a wildcard domain. 550 If at least one issuewild property is specified in the relevant CAA 551 record set, all issue properties MUST be ignored when processing a 552 request for a domain that is a wildcard domain. 554 A non-empty CAA record set that contains no issue or issuewild 555 property tags is authorization to any certificate issuer to issue for 556 the corresponding wildcard domain, provided that no records in the 557 CAA record set otherwise prohibit issuance. 559 5.4. CAA iodef Property 561 The iodef property specifies a means of reporting certificate issue 562 requests or cases of certificate issue for the corresponding domain 563 that violate the security policy of the issuer or the domain name 564 holder. 566 The Incident Object Description Exchange Format (IODEF) [RFC7970] is 567 used to present the incident report in machine-readable form. 569 The iodef property takes a URL as its parameter. The URL scheme type 570 determines the method used for reporting: 572 mailto: The IODEF incident report is reported as a MIME email 573 attachment to an SMTP email that is submitted to the mail address 574 specified. The mail message sent SHOULD contain a brief text message 575 to alert the recipient to the nature of the attachment. 577 http or https: The IODEF report is submitted as a Web service request 578 to the HTTP address specified using the protocol specified in 579 [RFC6546]. 581 6. Security Considerations 583 CAA records assert a security policy that the holder of a domain name 584 wishes to be observed by certificate issuers. The effectiveness of 585 CAA records as an access control mechanism is thus dependent on 586 observance of CAA constraints by issuers. 588 The objective of the CAA record properties described in this document 589 is to reduce the risk of certificate mis-issue rather than avoid 590 reliance on a certificate that has been mis-issued. DANE [RFC6698] 591 describes a mechanism for avoiding reliance on mis-issued 592 certificates. 594 6.1. Non-Compliance by Certification Authority 596 CAA records offer CAs a cost-effective means of mitigating the risk 597 of certificate mis-issue: the cost of implementing CAA checks is very 598 small and the potential costs of a mis-issue event include the 599 removal of an embedded trust anchor. 601 6.2. Mis-Issue by Authorized Certification Authority 603 Use of CAA records does not prevent mis-issue by an authorized 604 Certification Authority, i.e., a CA that is authorized to issue 605 certificates for the domain in question by CAA records. 607 Domain name holders SHOULD verify that the CAs they authorize to 608 issue certificates for their domains employ appropriate controls to 609 ensure that certificates are issued only to authorized parties within 610 their organization. 612 Such controls are most appropriately determined by the domain name 613 holder and the authorized CA(s) directly and are thus out of scope of 614 this document. 616 6.3. Suppression or Spoofing of CAA Records 618 Suppression of the CAA record or insertion of a bogus CAA record 619 could enable an attacker to obtain a certificate from an issuer that 620 was not authorized to issue for that domain name. 622 Where possible, issuers SHOULD perform DNSSEC validation to detect 623 missing or modified CAA record sets. 625 In cases where DNSSEC is not deployed in a corresponding domain, an 626 issuer SHOULD attempt to mitigate this risk by employing appropriate 627 DNS security controls. For example, all portions of the DNS lookup 628 process SHOULD be performed against the authoritative name server. 629 Data cached by third parties MUST NOT be relied on but MAY be used to 630 support additional anti-spoofing or anti-suppression controls. 632 6.4. Denial of Service 634 Introduction of a malformed or malicious CAA RR could in theory 635 enable a Denial-of-Service (DoS) attack. 637 This specific threat is not considered to add significantly to the 638 risk of running an insecure DNS service. 640 An attacker could, in principle, perform a DoS attack against an 641 issuer by requesting a certificate with a maliciously long DNS name. 642 In practice, the DNS protocol imposes a maximum name length and CAA 643 processing does not exacerbate the existing need to mitigate DoS 644 attacks to any meaningful degree. 646 6.5. Abuse of the Critical Flag 648 A Certification Authority could make use of the critical flag to 649 trick customers into publishing records that prevent competing 650 Certification Authorities from issuing certificates even though the 651 customer intends to authorize multiple providers. 653 In practice, such an attack would be of minimal effect since any 654 competent competitor that found itself unable to issue certificates 655 due to lack of support for a property marked critical SHOULD 656 investigate the cause and report the reason to the customer. The 657 customer will thus discover that they had been deceived. 659 7. Deployment Considerations 660 7.1. Blocked Queries or Responses 662 Some middleboxes, in particular anti-DDoS appliances, may be 663 configured to drop DNS packets of unknown types, or may start 664 dropping such packets when they consider themselves under attack. 665 This generally manifests as a timed-out DNS query, or a SERVFAIL at a 666 local recursive resolver. 668 For deployability of CAA and future DNS record types, middleboxes 669 SHOULD block DNS packets by volume and size rather than by query 670 type. 672 7.2. Rejected Queries and Malformed Responses 674 Some authoritative nameservers respond with REJECTED or NOTIMP when 675 queried for a resource record type they do not recognize. At least 676 one authoritative resolver produces a malformed response (with the QR 677 bit set to 0) when queried for unknown resource record types. Per 678 RFC 1034, the correct response for unknown resource record types is 679 NOERROR. 681 7.3. Delegation to Private Nameservers 683 Some domain administrators make the contents of a subdomain 684 unresolvable on the public internet by delegating that subdomain to a 685 nameserver whose IP address is private. A CA processing CAA records 686 for such subdomains will receive SERVFAIL from its recursive 687 resolver. The CA MAY interpret that as preventing issuance. Domain 688 administrators wishing to issue certificates for private domains 689 SHOULD use split-horizon DNS with a publicly available nameserver, so 690 that CAs can receive a valid, empty CAA response for those domains. 692 7.4. Bogus DNSSEC Responses 694 Queries for CAA resource records are different from most DNS RR 695 types, because a signed, empty response to a query for CAA RRs is 696 meaningfully different from a bogus response. A signed, empty 697 response indicates that there is definitely no CAA policy set at a 698 given label. A bogus response may mean either a misconfigured zone, 699 or an attacker tampering with records. DNSSEC implementations may 700 have bugs with signatures on empty responses that go unnoticed, 701 because for more common resource record types like A and AAAA, the 702 difference to an end user between empty and bogus is irrelevant; they 703 both mean a site is unavailable. 705 In particular, at least two authoritative resolvers that implement 706 live signing had bugs when returning empty resource record sets for 707 DNSSEC-signed zones, in combination with mixed-case queries. Mixed- 708 case queries, also known as DNS 0x20, are used by some recursive 709 resolvers to increase resilience against DNS poisoning attacks. 710 DNSSEC-signing authoritative resolvers are expected to copy the same 711 capitalization from the query into their ANSWER section, but sign the 712 response as if they had use all lowercase. In particular, PowerDNS 713 versions prior to 4.0.4 had this bug. 715 8. Differences versus RFC6844 717 This document obsoletes RFC6844. The most important change is to the 718 Certification Authority Processing section. RFC6844 specified an 719 algorithm that performed DNS tree-climbing not only on the domain 720 name being processed, but also on all CNAMEs and DNAMEs encountered 721 along the way. This made the processing algorithm very inefficient 722 when used on domains that utilize many CNAMEs, and would have made it 723 difficult for hosting providers to set CAA policies on their own 724 domains without setting potentially unwanted CAA policies on their 725 customers' domains. This document specifies a simplified processing 726 algorithm that only performs tree climbing on the domain being 727 processed, and leaves processing of CNAMEs and DNAMEs up to the CA's 728 recursive resolver. 730 This document also includes a "Deployment Considerations" section 731 detailing experience gained with practical deployment of CAA 732 enforcement amount CAs in the WebPKI. 734 This document clarifies the ABNF grammar for issue and issuewild tags 735 and resolves some inconsistencies with the document text. In 736 particular, it specifies that parameters are separated with hyphens. 737 It also allows hyphens in property names. 739 This document also clarifies processing of a CAA RRset that is not 740 empty, but contains no issue or issuewild tags. 742 9. IANA Considerations 744 This document has no IANA actions. 746 9.1. Certification Authority Restriction Flags 748 IANA has created the "Certification Authority Restriction Flags" 749 registry with the following initial values: 751 +------+----------------------+-----------+ 752 | Flag | Meaning | Reference | 753 +------+----------------------+-----------+ 754 | 0 | Issuer Critical Flag | [RFC6844] | 755 | | | | 756 | 1-7 | Reserved> | [RFC6844] | 757 +------+----------------------+-----------+ 759 Assignment of new flags follows the RFC Required policy set out in 760 [RFC8126], Section 4.1. 762 10. Acknowledgements 764 The authors would like to thank the following people who contributed 765 to the design and documentation of this work item: Chris Evans, 766 Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam 767 Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean 768 Turner, and Ben Wilson. 770 11. References 772 11.1. Normative References 774 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 775 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 776 . 778 [RFC1035] Mockapetris, P., "Domain names - implementation and 779 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 780 November 1987, . 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, 784 DOI 10.17487/RFC2119, March 1997, 785 . 787 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 788 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 789 . 791 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 792 Rose, "DNS Security Introduction and Requirements", 793 RFC 4033, DOI 10.17487/RFC4033, March 2005, 794 . 796 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 797 Rose, "Resource Records for the DNS Security Extensions", 798 RFC 4034, DOI 10.17487/RFC4034, March 2005, 799 . 801 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 802 Rose, "Protocol Modifications for the DNS Security 803 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 804 . 806 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 807 Security (DNSSEC) Hashed Authenticated Denial of 808 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 809 . 811 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 812 Specifications: ABNF", STD 68, RFC 5234, 813 DOI 10.17487/RFC5234, January 2008, 814 . 816 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 817 Housley, R., and W. Polk, "Internet X.509 Public Key 818 Infrastructure Certificate and Certificate Revocation List 819 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 820 . 822 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 823 Defense (RID) Messages over HTTP/TLS", RFC 6546, 824 DOI 10.17487/RFC6546, April 2012, 825 . 827 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 828 of Named Entities (DANE) Transport Layer Security (TLS) 829 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 830 2012, . 832 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 833 Authority Authorization (CAA) Resource Record", RFC 6844, 834 DOI 10.17487/RFC6844, January 2013, 835 . 837 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 838 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 839 November 2016, . 841 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 842 Writing an IANA Considerations Section in RFCs", BCP 26, 843 RFC 8126, DOI 10.17487/RFC8126, June 2017, 844 . 846 11.2. Informative References 848 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 849 Wu, "Internet X.509 Public Key Infrastructure Certificate 850 Policy and Certification Practices Framework", RFC 3647, 851 DOI 10.17487/RFC3647, November 2003, 852 . 854 Authors' Addresses 856 Phillip Hallam-Baker 857 Comodo Group, Inc 859 Email: philliph@comodo.com 861 Rob Stradling 862 Comodo Group, Inc 864 Email: rob.stradling@comodo.com 866 Jacob Hoffman-Andrews 867 Let's Encrypt 869 Email: jsha@letsencrypt.org