DNSSEC – A Foundation For Trust, PKI 2.0 Transformation And Preparation For Post Quantum Cryptography

Domain Name System (DNS) is essential for the proper functioning of the internet and is the first pillar of trust for every digital transaction. Every web page visited, every email, every digital communication leverages DNS to translate human friendly names to machine identifiers (IP addresses). Think of DNS as the phonebook of the internet. Most DNS deployments have not changed much since the 80s and still use clear text without validation or verification of the responses. Invariably, we blindly trust DNS to translate human friendly names and to direct them to the right machines. This blind trust creates risks such as spoofing, cache poisoning and impersonation attacks today. DNSSEC is a critical foundation of trust that can enable the path to PKI 2.0 transformation.

How DNSSEC Improves DNS Security

DNS Security Extensions (DNSSEC) was introduced by the Internet Engineering Task Force (IETF) to implement better authentication, encryption and validation of DNS responses. DNSSEC uses digital signatures based on Public Key Cryptography to sign the responses by the owner of the domain. There are two main functions of DNSSEC,

1. Data Origin Authentication allows resolvers/clients to cryptographically verify that the responses actually came from the owner of the DNS Name.
2. Data Integrity Protection allows the resolver/clients to verify that the data has not been modified in transit.

This is implemented using Public Key Cryptography where the root zone’s public key is trusted by the resolver/clients, which forms the foundation of trust for the internet and is called the trust anchor. From this trust anchor, resolvers can verify and validate the chain of trust which is the sequence of cryptographic keys signing other keys to verify and validate the DNS names and its IP address.

Certificates are another form of trust to validate and verify the end points like websites and servers. They also use Public Key Cryptography or Public Key Infrastructure (PKI). The public keys from issuing Certificate Authorities (CA) are embedded in device trust stores or browsers that are used to verify the end point certificates that are deployed in servers or websites. The root CA certificate is used to verify and validate the certificates it has issued, just like how you would trust a country’s passport if you trust the country’s government to securely issue passports to its citizens.

Today browsers have Google CA and 160+ other public CAs such as DigiCert, Sectigo, Entrust, GobalSign, etc., in their trust stores. Therefore, all of the websites that have certificates signed by Google CA or other public CAs will be trusted by the browser. Inherently, the Internet is an insecure and open network and trusting 160+ CAs does not inspire confidence in its security especially with state actors owning some of these CAs.

DNSSEC Enables PKI 2.0 Transformation

Explicit trust or Zero Trust is possible when the owner of the DNS name or enterprise publishes the Certificate Authority being used to sign the certificate of its website or server. Using DNSSEC, the owner of the DNS name publishes the web server or service details authoritatively and with integrity to verify the legitimacy. With PKI 2.0, the same DNS can be used to authoritatively with verifiable legitimacy publish the CA that is used to sign the endpoint certificate of the web server or services. This enables dual verification of trusted certificates directly from the DNS name owners and also verifies that the DNS names have the right CAs that are used to verify the certificates.

PKI 2.0 can leverage the DNSSEC Trust Anchor to verify and validate the CA or Certificate Trust Anchors using DNS based records for example DNS-Based Authentication of Named Entities (DANE) that allows the publication of Transport Layer Security (TLS) Keys in zones for applications. DANE provides a way to verify the authenticity of public keys that does not rely on CAs or as a second factor to the Certificate Authority list. This method does not implicitly trust certificates from the 160+ CAs, but just the certificate that the DNS name owner has used.

PKI 2.0 Enhances Enterprise Security

While changes have been incremental in the past 35 years of PKI deployments, it has now become the foundation of trust and encryption for digital communications. Major transformations are underway with Post Quantum Cryptography and Zero Trust Architectures driving PKI 2.0. These changes include new types of algorithms, enhanced protocols and security measures, enhanced trust anchors and hardware-based security elements. While PKI is evolving for the new world, these foundational changes in its implementation will enable explicit trust for certificates and true crypto-agility to prepare for short-lived certificates coming with Google’s 90-day TLS validity proposal and Post Quantum Cryptography.

The transformational changes of PKI can be classified into the following categories to enhance security and agility across the organization while leveraging some of the existing DNS technologies to achieve the same.

Zero Trust Architecture

The core foundation of Zero Trust is to implicitly not trust any entity. As per NIST SP 800-208A publications, Zero Trust assumes that there is no implicit trust granted to assets or user accounts based solely on their physical or network location or on asset ownership. Zero Trust focuses on protecting resources rather than network segments, as the network location is no longer seen as the prime component to the security posture of the resource. To enable these security controls, managing the foundations of trust is critical for machine-to-machine communications and implementing asymmetric encryption and TLS access controls.

Crypto-Agility

Enterprise crypto agility refers to an organization’s ability to adapt and manage cryptographic algorithms and protocols within their IT infrastructure and security systems. It involves the capability to seamlessly upgrade or replace cryptographic algorithms, key sizes, and cryptographic protocols to ensure continued security and compliance with evolving standards and best practices. Enterprise crypto-agility is important for several reasons:

Security: Cryptographic algorithms and protocols can become vulnerable over time due to advances in computing power or the discovery of new attacks. Enterprises need to have the ability to replace compromised or weakened algorithms with stronger alternatives to maintain the security of their data and communications.

Compliance: Industry standards and regulatory requirements often mandate the use of specific cryptographic algorithms or minimum key sizes. Enterprises must be able to adapt their cryptographic systems to comply with these standards and regulations, ensuring that sensitive data remains protected and that they meet legal and regulatory obligations.

Interoperability: In complex enterprise environments, different systems, applications, and vendors may use different cryptographic algorithms and protocols. Crypto-agility enables enterprises to support interoperability by allowing the use of multiple algorithms and protocols, ensuring secure communication between various components of their infrastructure.

Short Lived Certificate Support

With its 90-day TLS certificate validity proposal, Google is accelerating the move to short lived certificates for an improved security posture. This is the approach LetsEncrypt with its ACME protocol has supported to issue 90-day free TLS certificates for close to a decade. It is time for enterprises to adopt this best practice across both private enterprise CAs and public CAs for internet facing applications. Enabling short lived certificates also enhances crypto-agility of the organization. Additionally, we must look at this issue holistically where not only the end certificate is short lived, but also the renewal of the Issuer and root certificates are supported using automation and the PKI 2.0 approach.

AppViewX Supports PKI 2.0 Implementation

AppViewX integrates with all the leading DNS providers to set up DNSSEC automation and to rotate Domain Signing (DS) Keys and publish PKI Root CAs as DANE or CERT records for Trust Store management, automation and validation to enable crypto-agility. With PKI-as-a-Service (PKIaaS) and certificate lifecycle automation solution and support for Auto Enrollment Protocols, AppViewX can utilize PKI 2.0 to help enterprises achieve true crypto agility.

By publishing TLSA records in DNS, domain owners can specify the certificate usage, selector, and matching type for a particular TLS connection. This includes the ability to specify the cryptographic algorithm and parameters used in the associated certificate or public key.

In the context of crypto agility, TLSA records can be used to indicate that a domain supports multiple certificates with different cryptographic algorithms or parameters. This allows clients to choose the appropriate certificate or key based on their own capabilities and security requirements.

For example, if a domain owner wants to transition from using an old cryptographic algorithm to a newer and more secure one, they can publish both certificates in TLSA records, each corresponding to a different algorithm. Clients can then select the appropriate certificate based on their supported algorithms, enabling a smooth transition to stronger cryptography without immediate disruption.

In summary, TLSA records provide a mechanism for domain owners to express their crypto-agility by indicating the supported certificates and cryptographic algorithms, allowing clients to adapt and negotiate the most suitable and secure TLS connection.

To learn more about DNSSEC, PKI 2.0 and AppViewX solutions, please connect with us to set up a meeting.