https://DevOpsCloud.io -- Cloud Monk Losang Jinpa, Ph.D., MCSE/MCT, GitOps DevOps Engineer

Return to Security-Related RFCs, Network Security, Container Security - Kubernetes Security, Cloud Security, Web Security, DevSecOps

See: 6698 on datatracker.ietf.org

RFC 6698 introduces the DNS-Based Authentication of Named Entities (DANE) protocol, which provides a method for securely associating X.509 certificates with Domain Name System (DNS) names using DNSSEC (Domain Name System Security Extensions). The primary goal of RFC 6698 is to enhance the security of the existing public key infrastructure (PKI) by allowing domain owners to specify which certificate authorities (CAs) are authorized to issue certificates for their domain or to use their own certificates directly without relying on a traditional CA.

Before the introduction of RFC 6698, the certificate validation process relied heavily on trust in the global network of CAs, which could issue certificates for any domain. This centralized trust model presented significant security risks because if a single CA were compromised, attackers could potentially issue fraudulent certificates for any domain, allowing them to impersonate legitimate websites. RFC 6698 mitigates this risk by giving domain owners more control over the certificate validation process through DNSSEC-secured records.

In RFC 6698, the TLSA (Transport Layer Security Authentication) resource record is defined as the key mechanism for associating certificates with domain names. The TLSA record allows a domain owner to publish the certificate or certificate fingerprints directly in the DNS zone, protected by DNSSEC signatures. This ensures that the integrity and authenticity of the certificate information can be verified by any client using DNSSEC-enabled resolvers.

DANE, as described in RFC 6698, supports multiple usage modes. One mode allows domain owners to specify the exact certificate or public key that should be used for securing connections to their domain, bypassing the need to trust a third-party CA entirely. Another mode allows the domain owner to specify which CA is authorized to issue certificates for their domain, limiting the risk of rogue or unauthorized CAs issuing certificates. This flexibility is one of the core advantages of the DANE system.

RFC 6698 also discusses the deployment of DANE for securing TLS (Transport Layer Security) connections, which are commonly used to secure web traffic, email, and other services. By allowing domain owners to publish TLS certificate information in DNSSEC-protected records, DANE provides an additional layer of validation that helps protect against man-in-the-middle attacks and other types of certificate-based attacks.

A key feature of DANE is its reliance on DNSSEC, which ensures that the DNS responses containing TLSA records are authenticated and have not been tampered with. Without DNSSEC, the integrity of TLSA records could not be guaranteed, and an attacker could manipulate the DNS responses to provide fraudulent certificates. Therefore, the deployment of DANE is closely tied to the adoption of DNSSEC across the DNS infrastructure.

RFC 6698 also addresses the issue of certificate revocation. Traditionally, revoking certificates has been a challenge in the PKI system due to the complexity of managing certificate revocation lists (CRLs) and online certificate status protocols (OCSPs). By using DANE, domain owners can update their TLSA records in DNSSEC-protected zones, effectively revoking old certificates or specifying new ones without relying on external CRL or OCSP infrastructure. This simplifies the revocation process and provides a faster response to compromised or expired certificates.

Another important aspect of RFC 6698 is its impact on privacy and security. The TLSA records published in DNSSEC provide transparency by allowing anyone with access to the DNS records to verify the authenticity of the associated certificates. However, this transparency also means that attackers could potentially observe which certificates are associated with a domain. To address this, DANE can be used in conjunction with DNS-over-HTTPS or DNS-over-TLS, which encrypt DNS queries and responses, preventing eavesdroppers from viewing the certificate associations.

RFC 6698 plays a significant role in improving the security of email systems, particularly in protecting the Simple Mail Transfer Protocol (SMTP). By using DANE, email servers can publish TLSA records that specify the expected TLS certificates for their domain, ensuring that email traffic is protected from interception and tampering. This has made DANE an attractive solution for securing email communication in addition to web traffic.

The deployment of DANE and the implementation of RFC 6698 provide significant security benefits, but they also require a solid understanding of DNSSEC and proper TLS configuration. System administrators must ensure that their DNS zones are signed with DNSSEC and that the TLSA records are correctly configured to reflect the intended certificate usage. Misconfigurations could lead to service disruptions or a failure to establish secure connections.

In conclusion, RFC 6698 introduces the DANE protocol as a powerful tool for securing TLS connections and enhancing the certificate validation process by using DNSSEC-protected records. By allowing domain owners to publish certificate information directly in their DNS zones, DANE provides greater control over the certificate infrastructure and mitigates the risks associated with compromised certificate authorities. With its flexible usage modes and reliance on DNSSEC for authentication, DANE has become an important standard for securing internet communications. As DANE continues to gain adoption, it is expected to play a crucial role in improving the security of web traffic, email, and other services that rely on TLS. The full text of RFC 6698 is available on the IETF website at https://datatracker.ietf.org/doc/html/rfc6698.