CAA Security Tag for Cryptographic Domain Validation
draft-birgelee-lamps-caa-security-00

Limited Additional Mechanisms for PKIX and SMIME            H. Birge-Lee
Internet-Draft                                            G. Cimaszewski
Intended status: Experimental                           C. E. Krähenbühl
Expires: 18 May 2025                                             L. Wang
                                                    Princeton University
                                                                A. Gable
                                                                    ISRG
                                                               P. Mittal
                                                    Princeton University
                                                        14 November 2024

          CAA Security Tag for Cryptographic Domain Validation
                  draft-birgelee-lamps-caa-security-00

Abstract

   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.

About This Document

   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:[email protected]), 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.

Birge-Lee, et al.          Expires 18 May 2025                  [Page 1]
Internet-Draft              CAA Security Tag               November 2024

Status of This Memo

   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 Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Security CAA Record Syntax  . . . . . . . . . . . . . . . . .   3
   4.  Well-known Properties . . . . . . . . . . . . . . . . . . . .   4
   5.  Permissible Methods . . . . . . . . . . . . . . . . . . . . .   5
   6.  Permissible Options . . . . . . . . . . . . . . . . . . . . .   7
   7.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Single "security" Tag for Each Domain . . . . . . . . . . . .   8
   9.  CAA "security" Tag Protection . . . . . . . . . . . . . . . .   8
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

Birge-Lee, et al.          Expires 18 May 2025                  [Page 2]
Internet-Draft              CAA Security Tag               November 2024

1.  Introduction

   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.

2.  Conventions and Definitions

   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.

3.  Security CAA Record Syntax

   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

   1.  an empty string.

   2.  entirely whitespace.

Birge-Lee, et al.          Expires 18 May 2025                  [Page 3]
Internet-Draft              CAA Security Tag               November 2024

   3.  a property_list as defined in this document.

   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.

4.  Well-known Properties

   The top-level property_list MAY contain the following properties.

   1.  *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.

Birge-Lee, et al.          Expires 18 May 2025                  [Page 4]
Internet-Draft              CAA Security Tag               November 2024

   2.  *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.

   3.  *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.

5.  Permissible Methods

   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.

   1.  *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).

   2.  *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

Birge-Lee, et al.          Expires 18 May 2025                  [Page 5]
Internet-Draft              CAA Security Tag               November 2024

       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.

   3.  *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.

   4.  *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

Birge-Lee, et al.          Expires 18 May 2025                  [Page 6]
Internet-Draft              CAA Security Tag               November 2024

       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).

6.  Permissible Options

   The following options MAY used as parameters in the "options" or
   "options-critical" property in the top-level property_list.

   1.  *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.

7.  Applicability

   "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

Birge-Lee, et al.          Expires 18 May 2025                  [Page 7]
Internet-Draft              CAA Security Tag               November 2024

   certificate does not imply validation of any identity beyond the
   domain name(s) in the certificate.

8.  Single "security" Tag for Each Domain

   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.

9.  CAA "security" Tag Protection

   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.

10.  Security Considerations

   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

Birge-Lee, et al.          Expires 18 May 2025                  [Page 8]
Internet-Draft              CAA Security Tag               November 2024

   "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.

11.  IANA Considerations

   This document has no IANA actions.

12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Birge-Lee, et al.          Expires 18 May 2025                  [Page 9]
Internet-Draft              CAA Security Tag               November 2024

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Henry Birge-Lee
   Princeton University
   Email: [email protected]

   Grace Cimaszewski
   Princeton University
   Email: [email protected]

   Cyrill E. Krähenbühl
   Princeton University
   Email: [email protected]

   Liang Wang
   Princeton University
   Email: [email protected]

   Aaron Gable
   ISRG
   Email: [email protected]

   Prateek Mittal
   Princeton University
   Email: [email protected]

Birge-Lee, et al.          Expires 18 May 2025                 [Page 10]