Login
As part of Verisign’s ongoing effort to make global internet infrastructure more secure, stable, and resilient, we will soon make an important technology update to how we protect the top-level domains (TLDs) we operate. The vast majority of internet users won’t notice any difference, but the update will support enhanced security for several Verisign-operated TLDs and pave the way for broader adoption and the next era of Domain Name System (DNS) security measures.
Beginning in the next few months and continuing through the end of 2023, we will upgrade the algorithm we use to sign domain names in the .com, .net, and .edu zones with Domain Name System Security Extensions (DNSSEC).
In this blog, we’ll outline the details of the upcoming change and what members of the DNS technical community need to know.
DNSSEC provides data authentication security to DNS responses. It does this by ensuring any altered data can be detected and blocked, thereby preserving the integrity of DNS data. Think of it as a chain of trust – one that helps avoid misdirection and allows users to trust that they have gotten to their intended online destination safely and securely.
Verisign has long been at the forefront of DNSSEC adoption. In 2010, a major milestone occurred when the Internet Corporation for Assigned Names and Numbers (ICANN) and Verisign signed the DNS root zone with DNSSEC. Shortly after, Verisign introduced DNSSEC to its TLDs, beginning with .edu in mid-2010, .net in late 2010, and .com in early 2011. Additional TLDs operated by Verisign were subsequently signed as well.
In the time since we signed our TLDs, we have worked continuously to help members of the internet ecosystem take advantage of DNSSEC. We do this through a wide range of activities, including publishing technical resources, leading educational sessions, and advocating for DNSSEC adoption in industry and technical forums.
Since the TLDs were first signed, we have observed two very distinct phases of growth in the number of signed second-level domains (SLDs).
The first growth phase occurred from 2012 to 2020. During that time, signed domains in the .com zone grew at about 0.1% of the base per year on average, reaching just over 1% by the end of 2020. In the .net zone, signed domains grew at about 0.1% of the base per year on average, reaching 1.2% by the end of 2020. These numbers demonstrated a slow but steady increase, which can be seen in Figure 1.
Figure 1: A chart spanning 2010 through the present shows the number of .com and .net domain names with DS – or Delegation Signer – records. These records form a link in the DNSSEC chain-of-trust for signed domains, indicating an uptick in DNSSEC adoption among SLDs.
We’ve observed more pronounced growth in signed SLDs during the second growth phase, which began in 2020. This is largely due to a single registrar that enabled DNSSEC by default for their new registrations. For .com, the annual rate increased to 0.9% of the base, and for .net, it increased to 1.1% of the base. Currently, 4.2% of .com domains are signed and 5.1% of .net domains are signed. This accelerated growth is also visible in Figure 1.
As we look forward, Verisign anticipates continued growth in the number of domains signed with DNSSEC. To support continued adoption and help further secure the DNS, we’re planning to make one very important change.
All Verisign TLDs are currently signed with DNSSEC algorithm 8, also known as RSA/SHA-256, as documented in our DNSSEC Practice Statements. Currently, we use a 2048-bit Key Signing Key (KSK), and 1280-bit Zone Signing Keys (ZSK). The RSA algorithm has served us (and the broader internet) well for many years, but we wanted to take the opportunity to implement more robust security measures while also making more efficient use of resources that support DNSSEC-signed domain names.
We are planning to transition to the Elliptic Curve Digital Signature Algorithm (ECDSA), specifically Curve P-256 with SHA-256, or algorithm number 13, which allows for smaller signatures and improved cryptographic strength. This smaller signature size has a secondary benefit, as well: any potential DDoS attacks will have less amplification as a result of the smaller signatures. This could help protect victims from bad actors and cybercriminals.
Support for DNSSEC signing and validation with ECDSA has been well-established by various managed DNS providers, 78 other TLDs, and nearly 10 million signed SLDs. Additionally, research performed by APNIC and NLnet Labs shows that ECDSA support in validating resolvers has increased significantly in recent years.
How did we get to this point? It took a lot of careful preparation and planning, but with internet stewardship at the forefront of our mission, we wanted to protect the DNS with the best technologies available to us. This means taking precise measures in everything we do, and this transition is no exception.
Algorithm 13 was on our radar for several years before we officially kicked off the implementation process this year. As mentioned previously, the primary motivating properties were the smaller signature size, with each signature being 96 bytes smaller than our current RSA signatures (160 bytes vs. 64 bytes), and the improved cryptographic strength. This helps us plan for the future and prepare for a world where more domain names are signed with DNSSEC.
Each TLD will first implement the rollover to algorithm 13 in Verisign’s Operational Test & Evaluation (OT&E) environment prior to implementing the process in production, for a total of two rollovers per TLD. Combined, this will result in six total rollovers across the .com, .net, and .edu TLDs. Rollovers between the individual TLDs will be spaced out to avoid overlap where possible.
The algorithm rollover for each TLD will follow this sequence of events:
Only when a successful rollover has been done in OT&E will we begin the process in production.
Now that we’ve given the background, we know you’re wondering: how might this affect me?
The change to a new DNSSEC-signing algorithm is expected to have no impact for the vast majority of internet users, service providers, and domain registrants. According to the aforementioned research by APNIC and NLnet Labs, most DNSSEC validators support ECDSA, and any that do not will simply ignore the signatures and still be able to resolve domains in Verisign-operated TLDs.
Regarding timing, we plan to begin to transition to ECDSA in the third and fourth quarters of this year. We will start the transition process with .edu, then .net, and then .com. We are currently aiming to have these three TLDs transitioned before the end of the fourth quarter 2023, but we will let the community know if our timeline shifts.
As leaders in DNSSEC adoption, this algorithm rollover demonstrates yet another critical step we are taking toward making the internet more secure, stable, and resilient. We look forward to enabling the change later this year, providing more efficient and stronger cryptographic security while optimizing resource utilization for DNSSEC-signed domain names.
The post Verisign Will Help Strengthen Security with DNSSEC Algorithm Update appeared first on Verisign Blog.
In 2021, we discussed a potential future shift from established public-key algorithms to so-called “post-quantum” algorithms, which may help protect sensitive information after the advent of quantum computers. We also shared some of our initial research on how to apply these algorithms to the Domain Name System Security Extensions, or DNSSEC. In the time since that blog post, we’ve continued to explore ways to address the potential operational impact of post-quantum algorithms on DNSSEC, while also closely tracking industry research and advances in this area.
Now, significant activities are underway that are setting the timeline for the availability and adoption of post-quantum algorithms. Since DNS participants – including registries and registrars – use public key-cryptography in a number of their systems, these systems may all eventually need to be updated to use the new post-quantum algorithms. We also announce two major contributions that Verisign has made in support of standardizing this technology: an Internet-Draft as well as a public, royalty-free license to certain intellectual property related to that Internet-Draft.
In this blog post, we review the changes that are on the horizon and what they mean for the DNS ecosystem, and one way we are proposing to ease the implementation of post-quantum signatures – Merkle Tree Ladder mode.
By taking these actions, we aim to be better prepared (while also helping others prepare) for a future where cryptanalytically relevant quantum computing and post-quantum cryptography become a reality.
In July 2022, the National Institute of Standards and Technology (NIST) selected one post-quantum encryption algorithm and three post-quantum signature algorithms for standardization, with standards for these algorithms arriving as early as 2024. In line with this work, the Internet Engineering Task Force (IETF) has also started standards development activities on applying post-quantum algorithms to internet protocols in various working groups, including the newly formed Post-Quantum Use in Protocols (PQUIP) working group. And finally, the National Security Agency (NSA) recently announced that National Security Systems are expected to transition to post-quantum algorithms by 2035.
Collectively, these announcements and activities indicate that many organizations are envisioning a (post-)quantum future, across many protocols. Verisign’s main concern continues to be how post-quantum cryptography impacts the DNS, and in particular, how post-quantum signature algorithms impact DNSSEC.
The standards being developed in the next few years are likely to be the ones deployed when the post-quantum transition eventually takes place, so now is the time to take operational requirements for specific protocols into account.
For DNSSEC, the operational concerns are twofold.
First, the large signature sizes of current post-quantum signatures selected by NIST would result in DNSSEC responses that exceed the size limits of the User Datagram Protocol, which is broadly deployed in the DNS ecosystem. While the Transmission Control Protocol and other transports are available, the additional overhead of having large post-quantum signatures on every response — which can be one to two orders of magnitude as long as traditional signatures —introduces operational risk to the DNS ecosystem that would be preferable to avoid.
Second, the large signatures would significantly increase memory requirements for resolvers using in-memory caches and authoritative nameservers using in-memory databases.
Figure 1, from Andy Fregly’s recent presentation at OARC 40, shows the impact on a fully signed DNS zone where, on average, there are 2.2 digital signatures per resource record set (covering both existence and non-existence proofs). The horizontal bars show the percentage of the zone file that would be comprised of signature data for the two prevalent current algorithms, RSA and ECDSA, and for the smallest and largest of the NIST PQC algorithms. At the low and high end of these examples, signatures with ECDSA would take up 40% of the zone and SPHINCS+ signatures would take up over 99% of the zone. The vertical bars give the percentage size increase of the zone file due to signatures. Again, comparing the low and high end, a zone fully signed with SPHINCS+ would be about 50 times the size of a zone fully signed with ECDSA.
In his 1988 article, “The First Ten Years of Public-Key Cryptography,” Whitfield Diffie, co-discoverer of public-key cryptography, commented on the lack of progress in finding public-key encryption algorithms that were as fast as the symmetric-key algorithms of the day: “Theorems or not, it seemed silly to expect that adding a major new criterion to the requirements of a cryptographic system could fail to slow it down.”
Diffie’s counsel also appears relevant to the search for post-quantum algorithms: It would similarly be surprising if adding the “major new criterion” of post-quantum security to the requirements of a digital signature algorithm didn’t impact performance in some way. Signature size may well be the tradeoff for post-quantum security, at least for now.
With this tradeoff in mind, Verisign’s post-quantum research team has explored ways to address the size impact, particularly to DNSSEC, arriving at a construction we call a Merkle Tree Ladder (MTL), a generalization of a single-rooted Merkle tree (see Figure 2). We have also defined a technique that we call the Merkle Tree Ladder mode of operation for using the construction with an underlying signature algorithm.
Similar to current deployments of public-key cryptography, MTL mode combines processes with complementary properties to balance performance and other criteria (see Table 1). In particular, in MTL mode, rather than signing individual messages with a post-quantum signature algorithm, ladders comprised of one or more Merkle tree nodes are signed using the post-quantum algorithm. Individual messages are then authenticated relative to the ladders using Merkle authentication paths.
| Criterion to Achieve | Initial Design with a Single Process | Improved Design Combining Complementary Processes | Benefit |
| Public-Key Property for Encryption | – Encrypt Individual Messages with Public-Key Algorithm | – Establish Symmetric Keys Using Public-Key Algorithm – Encrypt Multiple Messages Using Each Symmetric Key |
– Amortize Cost of Public-Key Operations Across Multiple Messages |
| Post-Quantum Property for Signatures | – Sign Individual Messages with Post-Quantum Algorithm | – Sign Merkle Tree Ladders using Post-Quantum Algorithm – Authenticate Multiple Messages Relative to Each Signed Ladder |
– Amortize Size of Post-Quantum Signature Across Multiple Messages |
Although the signatures on the ladders might be relatively large, the ladders and their signatures are sent infrequently. In contrast, the Merkle authentication paths that are sent for each message are relatively short. The combination of the two processes maintains the post-quantum property while amortizing the size impact of the signatures across multiple messages. (Merkle tree constructions, being based on hash functions, are naturally post-quantum.)
The two-part approach for public-key algorithms has worked well in practice. In Transport Layer Security, symmetric keys are established in occasional handshake operations, which may be more expensive. The symmetric keys are then used to encrypt multiple messages within a session without further overhead for key establishment. (They can also be used to start a new session).
We expect that a two-part approach for post-quantum signatures can similarly work well in an application like DNSSEC where verifiers are interested in authenticating a subset of messages from a large, evolving message series (e.g., DNS records).
In such applications, signed Merkle Tree Ladders covering a range of messages in the evolving series can be provided to a verifier occasionally. Verifiers can then authenticate messages relative to the ladders, given just a short Merkle authentication path.
Importantly, due to a property of Merkle authentication paths called backward compatibility, all verifiers can be given the same authentication path relative to the signer’s current ladder. This also helps with deployment in applications such as DNSSEC, since the authentication path can be published in place of a traditional signature. An individual verifier may verify the authentication path as long as the verifier has a previously signed ladder covering the message of interest. If not, then the verifier just needs to get the current ladder.
As reported in our presentation on MTL mode at the RSA Conference Cryptographers’ Track in April 2023, our initial evaluation of the expected frequency of requests for MTL mode signed ladders in DNSSEC is promising, suggesting that a significant reduction in effective signature size impact can be achieved.
To facilitate more public evaluation of MTL mode, Verisign’s post-quantum research team last week published the Internet-Draft “Merkle Tree Ladder Mode (MTL) Signatures.” The draft provides the first detailed, interoperable specification for applying MTL mode to a signature scheme, with SPHINCS+ as an initial example.
We chose SPHINCS+ because it is the most conservative of the NIST PQC algorithms from a cryptographic perspective, being hash-based and stateless. It is arguably most suited to be one of the algorithms in a long-term deployment of a critical infrastructure service like DNSSEC. With this focus, the specification has a “SPHINCS+-friendly” style. Implementers familiar with SPHINCS+ will find similar notation and constructions as well as common hash function instantiations. We are open to adding other post-quantum signature schemes to the draft or other drafts in the future.
Publishing the Internet-Draft is a first step toward the goal of standardizing a mode of operation that can reduce the size impact of post-quantum signature algorithms.
In support of this goal, Verisign also announced this week a public, royalty-free license to certain intellectual property related to the Internet-Draft published last week. Similar to other intellectual property rights declarations the company has made, we have announced a “Standards Development Grant” which provides the listed intellectual property under royalty-free terms for the purpose of facilitating standardization of the Internet-Draft we published on July 10, 2023. (The IPR declaration gives the official language.)
We expect to release an open-source implementation of the Internet-Draft soon, and, later this year, to publish an Internet-Draft on using MTL mode signatures in DNSSEC.
With these contributions, we invite implementers to take part in the next step toward standardization: evaluating initial versions of MTL mode to confirm whether they indeed provide practical advantages in specific use cases.
DNSSEC continues to be an important part of the internet’s infrastructure, providing cryptographic verification of information associated with the unique, stable identifiers in this ubiquitous namespace. That is why preparing for an eventual transition to post-quantum algorithms for DNSSEC has been and continues to be a key research and development activity at Verisign, as evidenced by our work on MTL mode and post-quantum DNSSEC more generally.
Our goal is that with a technique like MTL mode in place, protocols like DNSSEC can preserve the security characteristics of a pre-quantum environment while minimizing the operational impact of larger signatures in a post-quantum world.
In a later blog post, we’ll share more details on some upcoming changes to DNSSEC, and how these changes will provide both security and operational benefits to DNSSEC in the near term.
Verisign plans to continue to invest in research and standards development in this area, as we help prepare for a post-quantum future.
The post Next Steps in Preparing for Post-Quantum DNSSEC appeared first on Verisign Blog.
FreshRSS 