DNS Certification Authority Authorization

Last updated

DNS Certification Authority Authorization
AbbreviationCAA
Status Proposed Standard
First publishedOctober 18, 2010 (2010-10-18)
Latest version RFC   8659
November 2019
Organization IETF
Authors

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

Contents

It was drafted by computer scientists Phillip Hallam-Baker and Rob Stradling in response to increasing concerns about the security of publicly trusted certificate authorities. It is an Internet Engineering Task Force (IETF) proposed standard.

Background

A series of incorrectly issued certificates from 2001 onwards [1] [2] damaged trust in publicly trusted certificate authorities, [3] and accelerated work on various security mechanisms, including Certificate Transparency to track mis-issuance, HTTP Public Key Pinning and DANE to block mis-issued certificates on the client-side, and CAA to block mis-issuance on the certificate authority side. [4]

The first draft of CAA was written by Phillip Hallam-Baker and Rob Stradling, and submitted as an IETF Internet Draft in October 2010. [5] This was progressively improved by the PKIX Working Group, [6] and approved by the IESG as RFC   6844, a Proposed Standard, in January 2013. [7] CA/Browser Forum discussion began shortly afterward, [4] and in March 2017 they voted in favor of making CAA implementation mandatory for all certificate authorities by September 2017. [8] [9] At least one certificate authority, Comodo, failed to implement CAA before the deadline. [10] A 2017 study by the Technical University of Munich found many instances where certificate authorities failed to correctly implement some part of the standard. [4]

In September 2017, Jacob Hoffman-Andrews submitted an Internet Draft intended to simplify the CAA standard. This was improved by the LAMPS Working Group, and approved as RFC   8659, a Proposed Standard, in November 2019. [11]

As of January 2020, Qualys reports that still, only 6.8% of the 150,000 most popular TLS-supporting websites use CAA records. [12]

Record

Certificate authorities implementing CAA perform a DNS lookup for CAA resource records, and if any are found, ensure that they are listed as an authorized party before issuing a digital certificate. Each CAA resource record consists of the following components: [11]

flag
A flags byte which implements an extensible signaling system for future use. As of 2018, only the issuer critical flag has been defined, which instructs certificate authorities that they must understand the corresponding property tag before issuing a certificate. [11] This flag allows the protocol to be extended in the future with mandatory extensions, [4] similar to critical extensions in X.509 certificates.
tag
One of the following property:
issue
This property authorizes the holder of the domain specified in associated property value to issue certificates for the domain for which the property is published.
issuewild
This property acts like issue but only authorizes the issuance of wildcard certificates, and takes precedence over the issue property for wildcard certificate requests.
iodef
This property specifies a method for certificate authorities to report invalid certificate requests to the domain name holder using the Incident Object Description Exchange Format. As of 2018, not all certificate authorities support this tag, so there is no guarantee that all certificate issuances will be reported.
contactemail
Increasingly, contact information is not available in WHOIS due to concerns about potential GDPR violations. This property allows domain holders to publish contact information in DNS. [13] [14]
contactphone
As above, for phone numbers. [15]
value
The value associated with the chosen property tag.

The lack of any CAA records authorizes normal unrestricted issuance, and the presence of a single blank issue tag disallows all issuance. [11] [9] [16]

Third parties monitoring certificate authority behavior might check newly issued certificates against the domain's CAA records. RFC   8659 states; CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take into account the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator. [11]

Extensions

RFC   8657 specifies "accounturi" and "validationmethods" parameters which allow users to specify desired methods of domain control validation as defined in ACME protocol. For example, website administrator can bind a domain they control to particular account registered with their desired Certification Authority.

History

A draft of the first extension to the CAA standard was published on October 26, 2016, proposing a new account-uri token to the end of the issue property, which ties a domain to a specific Automated Certificate Management Environment account. [17] This was amended on August 30, 2017, to also include a new validation-methods token, which ties a domain to a specific validation method, [18] and then further amended on June 21, 2018, to remove the hyphen in account-uri and validation-methods making them instead accounturi and validationmethods. [19]

Examples

To indicate that only the certificate authority identified by ca.example.net is authorized to issue certificates for example.com and all subdomains, one may use this CAA record: [11] 

example.com.INCAA0issue"ca.example.net"

To disallow any certificate issuance, one may allow issuance only to an empty issuer list:

example.com.INCAA0issue";"

To indicate that certificate authorities should report invalid certificate requests to an email address and a Real-time Inter-network Defense endpoint:

example.com.INCAA0iodef"mailto:security@example.com"example.com.INCAA0iodef"http://iodef.example.com/"

To use a future extension of the protocol, for example, one which defines a new future property, which needs to be understood by the certificate authority before they can safely proceed, one may set the issuer critical flag:

example.com.INCAA0issue"ca.example.net"example.com.INCAA128future"value"

Incidents

In 2017, Camerfirma was found to improperly validate CAA records. Camerfirma claimed to have misunderstood the CA/Browser Forum Baseline Requirements describing CAA validation. [20] [4]

In early 2020, Let's Encrypt disclosed that their software improperly queried and validated CAA records potentially affecting over 3 million certificates. [21] Let's Encrypt worked with customers and site operators to replace over 1.7 million certificates, but decided not to revoke the rest to avoid client downtime and since the affected certificates would all expire in less than 90 days. [22]

See also

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

The Domain Name System Security Extensions (DNSSEC) are a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

A Service record is a specification of data in the Domain Name System defining the location, i.e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.

Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "To:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

MARID was an IETF working group in the applications area tasked to propose standards for email authentication in 2004. The name is an acronym of MTA Authorization Records In DNS.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing email, email scams and other cyber threat activities.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

PKI Resource Query Protocol (PRQP) is an Internet protocol used for obtaining information about services associated with an X.509 Certificate Authority. It is described by RFC 7030 published on October 23, 2013. PRQP aims to improve Interoperability and Usabilities issues among PKIs, helping finding services and data repositories associated with a CA. Messages communicated via PRQP are encoded in ASN.1 and are usually communicated over HTTP.

Resource Public Key Infrastructure (RPKI), also known as Resource Certification, is a specialized public key infrastructure (PKI) framework to support improved security for the Internet's BGP routing infrastructure.

<span class="mw-page-title-main">Wildcard certificate</span> Public key certificate which can be used with multiple subdomain of a domain

In computer networking, a wildcard certificate is a public key certificate which can be used with multiple sub-domains of a domain. The principal use is for securing web sites with HTTPS, but there are also applications in many other fields. Compared with conventional certificates, a wildcard certificate can be cheaper and more convenient than a certificate for each sub-domain. Multi-domain wildcard certificates further simplify the complexity and reduce costs by securing multiple domains and their sub-domains.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Phillip Hallam-Baker is a computer scientist, mostly known for contributions to Internet security, since the design of HTTP at CERN in 1992. Self-employed since 2018 as a consultant and expert witness in court cases, he previously worked at Comodo, Verisign, and the MIT Artificial Intelligence Laboratory. He is a frequent participant in IETF meetings and discussions, and has written a number of RFCs. In 2007 he authored the dotCrime Manifesto: How to Stop Internet Crime; Ron Rivest used it as a source of project ideas for his course on Computer and Network Security at MIT in 2013.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

HTTP Public Key Pinning (HPKP) is an obsolete Internet security mechanism delivered via an HTTP header which allows HTTPS websites to resist impersonation by attackers using misissued or otherwise fraudulent digital certificates. A server uses it to deliver to the client a set of hashes of public keys that must appear in the certificate chain of future connections to the same domain name.

<span class="mw-page-title-main">Automatic Certificate Management Environment</span> Communications protocol for automating interactions between certificate authorities and web servers

The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users' servers, allowing the automated deployment of public key infrastructure at very low cost. It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service.

<span class="mw-page-title-main">Well-known URI</span>

A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with /.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.

References

  1. ↑ Ristić, Ivan. "SSL/TLS and PKI History". Feisty Duck. Retrieved June 8, 2018.
  2. ↑ Bright, Peter (August 30, 2011). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica . Retrieved February 10, 2018.
  3. ↑ Ruohonen, Jukka (2019). "An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization". Journal of Cyber Security Technology. 3 (4): 205–218. arXiv: 1804.07604 . doi:10.1080/23742917.2019.1632249. S2CID   5027899.
  4. 1 2 3 4 5 Scheitle, Quirin; Chung, Taejoong; et al. (April 2018). "A First Look at Certification Authority Authorization (CAA)" (PDF). ACM SIGCOMM Computer Communication Review. 48 (2): 10–23. doi:10.1145/3213232.3213235. ISSN   0146-4833. S2CID   13988123.
  5. ↑ Hallam-Baker, Phillip; Stradling, Rob (October 18, 2010). DNS Certification Authority Authorization (CAA) Resource Record. IETF. I-D draft-hallambaker-donotissue-00.
  6. ↑ Hallam-Baker, Phillip; Stradling, Rob; Ben, Laurie (June 2, 2011). DNS Certification Authority Authorization (CAA) Resource Record. IETF. I-D draft-ietf-pkix-caa-00.
  7. ↑ Hallam-Baker, Phillip; Stradling, Rob (January 2013). DNS Certification Authority Authorization (CAA) Resource Record. IETF. doi: 10.17487/RFC6844 . ISSN   2070-1721. RFC 6844.
  8. ↑ Hall, Kirk (March 8, 2017). "Results on Ballot 187 - Make CAA Checking Mandatory". CA/Browser Forum . Retrieved January 7, 2018.
  9. 1 2 Beattie, Doug (August 22, 2017). "What is CAA (Certificate Authority Authorization)?". GlobalSign . Retrieved February 2, 2018.
  10. ↑ Cimpanu, Catalin (September 11, 2017). "Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect". Bleeping Computer . Retrieved January 8, 2018.
  11. 1 2 3 4 5 6 DNS Certification Authority Authorization (CAA) Resource Record. IETF. November 2019. doi: 10.17487/RFC8659 . ISSN   2070-1721. RFC 8659.
  12. ↑ "SSL Pulse". SSL Labs. Qualys. January 3, 2020. Retrieved January 31, 2020.
  13. ↑ "Public Key Infrastructure using X.509 (PKIX) Parameters". www.iana.org. Retrieved August 22, 2020.
  14. ↑ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf [ bare URL PDF ]
  15. ↑ Beattie, Doug (January 7, 2019). "Ballot SC14: CAA Contact Property and Associated Phone Validation Methods". CA/Browser Forum (Mailing list). Retrieved October 19, 2020.
  16. ↑ "What is Certificate Authority Authorization (CAA)?". Symantec . Retrieved January 8, 2018.
  17. ↑ Landau, Hugo (October 26, 2016). CAA Record Extensions for Account URI and ACME Method Binding. IETF. I-D draft-ietf-acme-caa-00.
  18. ↑ Landau, Hugo (August 30, 2017). CAA Record Extensions for Account URI and ACME Method Binding. IETF. I-D draft-ietf-acme-caa-04.
  19. ↑ Landau, Hugo (June 21, 2018). CAA Record Extensions for Account URI and ACME Method Binding. IETF. I-D draft-ietf-acme-caa-05.
  20. ↑ "CA:Camerfirma Issues - MozillaWiki". wiki.mozilla.org. Retrieved April 27, 2021.
  21. ↑ Claburn, Thomas (March 3, 2020). "Let's Encrypt? Let's revoke 3 million HTTPS certificates on Wednesday, more like: Check code loop blunder strikes". www.theregister.com. Archived from the original on May 31, 2020. Retrieved April 27, 2021.
  22. ↑ Barrett, Brian (March 3, 2020). "The Internet Avoided a Minor Disaster Last Week". Wired. ISSN   1059-1028 . Retrieved April 27, 2021.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.