| Internet-Draft | CAA Security Tag | November 2024 |
| Birge-Lee, et al. | Expires 18 May 2025 | [Page] |
CAA "security" tags are a type of CAA record (defined in RFC 6844) with the critical flag set that specify that for a certificate to be issued, the issuance process must be conducted in a manner that is robust against global man-in-the-middle adversaries by leveraging authenticated communication between a CA and a domain. Cryptographic domain validation procedures are authenticated and resilient against attacks by both on-path and off-path network attackers which may be between the CA and the domain contained in the certificate. This document defines the syntax of "security" CAA records as well as acceptable means for validating domains in a cryptographic manner.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://birgelee.github.io/draft-caa-security-tag/draft-birgelee-lamps-caa-security.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-birgelee-lamps-caa-security/.¶
Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.¶
Source for this draft and an issue tracker can be found at https://github.com/birgelee/draft-caa-security-tag.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 18 May 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A "security" CAA record is compliant with RFC 6844 and puts restrictions on the circumstances under which a CA can sign a certificate for a given domain. A “security” CAA record on a domain implies that validation for this domain must be done in a manner that offers security against network adversaries even if an adversary is capable of intercepting and/or modifying communication between the CA and the domain being validated. Issuance of a certificate to a domain with a "security" CAA tag MUST follow one of the specified Cryptographic Domain Validation (CDV) methods outlined in this document or future extensions. CDV methods MUST rely on cryptographic protocols (like DNSSEC or DoH/DoT) that offer security properties even in the presence of man-in-the-middle adversaries that can intercept any communication which occurs over the public Internet.¶
Not all CDV methods are in themselves compliant with the CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates. Any CDV method that does not additionally meet the CA/Browser Forum Baseline Requirements for TLS server certificate issuance must be used in conjunction with a method that satisfies CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates. Such methods are indicated in their descriptions.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The flags field of the security tag MUST have the critical bit set in the flags byte of the CAA record.¶
The "security" tag MUST have the tag field of the CAA record be the word "security".¶
The value field of the "security" tag MUST be one of three values¶
Values 1. and 2. MUST be treated identically as an empty value field.¶
A property_list is defined by the following syntax¶
[whitespace]<property>[whitespace][,[whitespace]<property>[whitespace] ...]¶
A property is defined as¶
<property_name>[whitespace][(property_list)]¶
property_name is a name that identifies the property being specified. The name MUST consist only of lowercase letters (a-z), uppercase letters (A-Z), numbers (0-9), colin (:), underscore (_), and hyphen (-). Names are case sensitive.¶
Properties can optionally have parameters specified in parenthesis. The parameteres of a property are a property_list. A property with no parameters MUST NOT be followed by parenthesis (i.e., property_name() is not a valid statement).¶
The optional property_list specified in parenthesis after each property contains parameters associated with that property.¶
A property_list can be arbitrarily long. Whitespace between properties is ignored. properties are comma-separated. property_lists MUST NOT be empty (i.e., property_lists must have at least one property). All properties specified in a property_list MUST be unique. A property_list MUST NOT have two of the same properties specified even if they contain different parameters.¶
The top-level property_list MAY contain the following properties.¶
methods If specified, this property MUST have parameters listing various cryptographic domain validation methods that can be used to validate that particular domain. A CA MUST only use one of the methods specified in the parameters value_list to perform cryptographic domain validation. If there is no method specified that the CA is capable of complying with, the CA MUST deny issuance.¶
options If specified, this property MUST have parameters listing various options. A CA SHOULD try to honor any option specified in this list. If a CA does not understand an option or does not have that option implemented the, CA MAY proceed with issuance.¶
options-critical If specified, this property MUST have parameters listing various options. To proceed with issuance, a CA MUST understand and implement all options specified in the options-critical parameter's property-list¶
The top-level property_list MAY contain additional properties and a CA MAY proceed with issuance even if it does not understand these additional properties. Subsequent RFCs MAY standardize these properties.¶
The following properties MAY be specified as parameters of the "methods" property. Each method specifies particular aspects of certificate issuance that MUST be satisfied for a certificate to be issued using that method. While some methods entail the use of CA/Browser Forum-compliant domain control validation methods, others do not entail CA/Browser Forum-compliant domain control validation and must be used in conjunction with a CA/Browser Forum-compliant domain control validation method to permit certificate issuance.¶
secure-dns-record-change: This method involves an applicant showing control of a DNSSEC-protected DNS record or a record that was retrieved via a DoH or DoT tunnel to the relevant authoritative nameservers used in the DNS resolution. This can be done via 1) the validation method "DNS Change" specified in the CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates (Section 3.2.2.4.7) or 2) the "dns-01" method of the ACME RFC 8555. For this method to be satisfied, the FQDN where the DNS change is demonstrated MUST be protected by DNSSEC or lookups to the relevant authoritative nameservers MUST be conducted over authenticated channels (e.g., DoH/DoT).¶
http-validation-over-tls: This method involves the completion of an HTTP domain validation challenge over an HTTPS session using TCP port 443 where the server authenticates with an existing publicly-trusted valid certificate covering the domain in question. The certificate cannot be self-signed or expired. This method MAY be directly satisfied while a CA is performing the "Agreed‑Upon Change to Website v2" domain control validation method specified in the the CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates (Section 3.2.2.4.18). The ACME "http-01" challenge specified in RFC 8555 does not permit the use of HTTPS or port 443 when a CA is contacting the domain in question. A CA MAY still satisfy the http-validation-over-tls method even if it does not initiate connections to port 443 for HTTP challenges so long as either 1) the connection initiated to port 80 serves a redirect to the same domain name over HTTPS at port 443 and the connection to the domain at port 443 servers a valid, trusted certificate or 2) in addition to contacting the domain over port 80 the CA also contacts the domain over port 443 using HTTPS and the connection is established with a valid, trusted certificate and the same challenge value is observed. Operators of security-critical domains MAY choose not to permit this method since, unlike other cryptographic domain validation methods specified in this document, its security relies on no malicious certificates existing for a domain at time of the creation of the "security" tag in the domain's policy.¶
known-account-specifier: For a CA to issue a certificate using this method 1) there MUST exist a unique identifier for a CA subscriber account that is communicated with the CA out-of-band, over authenticated DNS lookups, or in another manner that is immune to man-in-the-middle adversaries 2) the CA may only issue a certificate to an applicant that has authenticated itself to the CA as having access to that specified subscriber account. A CA does not have permission to issue under this method unless both of these criteria are met. Once these criteria have been met, the CA MUST additionally perform a validation method that is compliant with the Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates. One acceptable way of including this account identifier is with the CAA ACME account URI extension in an authenticated DNS record.¶
private-key-control: This method involves an applicant showing control of a private key that corresponds to a public key placed in a DNS record associated with the domain being validated. The private key must be used to sign a message containing: a unique identifier for the CA, the domain name(s) in the certificate, a timestamp, and a hash of the public key in the certificate. This message may be hashed and then have the signature generated over the hash of this message. Obtaining such a signed message from a certificate applicant authorizes the CA specified in the message to sign a certificate for those domain names with the specified public key within 24h of the timestamp provided in the message. The CA MUST retrieve the public key or a hash of the public key corresponding to the private key used for signing the message via an authenticated DNS lookup using either authenticated channels to the relevant authoritative nameservers (e.g., DoH or DoT) or validation of a DNSSEC signature chain back to the ICANN root. After private key control is established, the CA MUST additionally perform a validation method that is compliant with the Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates.¶
In the event that no "methods" property specified in the top-level property_list, all methods specified in this document are acceptable as well as cryptographic domain validation defined in future RFCs. Future RFCs MAY specify additional methods for cryptographic domain validation so long as they satisfy the properties of cryptographic domain validation (i.e., robust against global man-in-the-middle adversaries).¶
The following options MAY used as parameters in the "options" or "options-critical" property in the top-level property_list.¶
authenticated-policy-retrival: This option signifies to a CA that it MUST retrive a domain's "security" tag and any associated domain-owner identity (e.g., identifiers used for known-account-specifier and private-key-control) using authenticated DNS lookups or other authenticated channels. If a CA finds this option as a parameter to the "options-critical" property and the "security" tag was not retrieved using authenticated DNS lookups, the CA MUST NOT issues a certificate for that domain.¶
Additionally, a CA MAY choose to honor its own non-standardized options that do not need to be supported by other CAs or the IETF. These options MUST be prefixed with "-<ca_name>-" where ca_name is the name of the CA that initially developed the option.¶
"security" CAA tags can be used on domains that are contained in both domain validation certificates (where only the domain name in a certificate is validated) and extended or organization validated certificates (where information like organization identity as well as domain name is validated). Cryptographic Domain Validation only hardens the security of the validation of domain names, not broader identities (e.g., organization names). The use of cryptographic domain validation in an OV or EV certificate only improves the validation of the domain name(s) contained in the certificate (in the common name or subject-alternate names fields) and does not impact the validation of other forms of identity contained in the certificate. Use of cryptographic domain validation in a DV certificate does not imply validation of any identity beyond the domain name(s) in the certificate.¶
A single domain CANNOT have multiple "security" tags specified. A domain's entire cryptographic domain validation policy MUST be encoded into a single "security" tag. If a CA finds a domain that has multiple "security" CAA tags at the same FQDN, the CA MUST block issuance.¶
A "security" CAA tag SHOULD be protected with a valid DNSSEC signature chain going back to the ICANN DNSSEC root or hosted on authoritative DNS servers that CAs have authenticated communication channels with. Any "security" CAA record not protected by such a signature MAY not benefit from the security properties outlined in this document. If it is not possible to have a DNSSEC signature chain back to the ICANN root, "security" CAA records SHOULD alternately be hosted in an authoritative DNS resolver that supports recursive-to-authoritative DNS over TLS or DNS over HTTPS. CAs SHOULD also require recursive-to-authoritative DNS over TLS or DNS over HTTPS communication (and not permit standard unencrypted DNS connections) for DNS providers that host "security" CAA records. This prevents downgrade attacks where an adversary attempts to interfere with the establishment of a DNS over TLS or DNS over HTTPS encrypted channel and cause a fallback to unencrypted DNS over UDP/TCP.¶
Serving "security" CAA records over authenticated DNS channels or using authenticated DNS records (i.e., DNSSEC) is critical to the effectiveness of the records because a "security" CAA record not protected by authenticated DNS may be suppressed by an adversary that can manipulate DNS responses. This could potentially allow the adversary to downgrade validation to use a low-security method and undermine the security properties of the "security" tag.¶
Many of the security considerations regarding "security" CAA records are inherited from those of CAA records more generally. Because "security" CAA records do not introduce any new methods for validating domain ownership, they do not increase the attack surface of fraudulent validations. "security" CAA records reduce the attack surface of fraudulent validations by limiting which validation methods may be used and thus eliminating the risk posed by less-secure validation methods. Particularly, domains without a "security" CAA record are often highly vulnerable to man-in-the-middle adversaries that can intercept communications from a CA to the victim's domain. This record significantly reduces this attack surface.¶
As with any restriction on certificate issuance, this introduces the potential for a Denial of Service attack (or DoS attack). There are two potential approaches to launching a DoS attack via "security" CAA records. The first is to attack a domain and spoof the existence of a "security" CAA record in order to prevent the domain owner from renewing his or her certificate (presuming the domain under attack was not using a validation method compliant with the "security" CAA record). This attack vector is not novel to "security" CAA records and is enabled solely by following RFC 6844 alone. Per RFC 6844, the presence of any not-understood CAA record with the critical flag prevents issuance. Thus, the adoption of "security" CAA records does not increase the attack surface for this form of DoS attack as a gibberish CAA record with the critical flag set could enable this type of attack as well.¶
A second approach to a DoS attack enabled by "security" CAA records is to target a domain already using a "security" CAA record and interfere with all of the permitted validation methods with the idea that the presence of the "security" CAA will prevent the domain from falling back on alternative validation methods. This attack vector is mitigated by the diversity of different methods available to domain owners for validating domain ownership using "security" CAA records. A domain owner may use an alternate method to satisfy the "security" CAA record. In the event that a domain owner truly cannot satisfy any cryptographic domain validation method, the domain owner can still mitigate this attack by removing the "security" CAA record, obtaining a certificate, and then reinstating the "security" CAA record once the attack is over. As with all CAA records, CAs should not cache stale CAA record lookups that block issuance and should instead recheck the CAA record set when a new issuance request is received.¶
This document has no IANA actions.¶
TODO acknowledge.¶