Keys to internet names, critical, global infrastructure and a future market: DNSSEC & ECDSA
By Oleksandr Tsaruk, PhD, expert on Internet Governance and Cybersecurity
March 2017-Copenhagen, Denmark. ICANN 58
More than 2 000 participants from all over the world, all engaged in internet governance, attended the conference. Held for the first time in Denmark, the conference was noted the Danish internet community, the chance to strengthen its international relations, and discuss the future of the internet.
This was the 58th public meeting of ICANN – The Internet Corporation for Assigned Names and Numbers, a non-profit organization responsible for coordinating the maintenance and procedures of databases related to the numbers and namespaces of the Internet. A critical step to ensuring stable networks and secure operations.
ICANN was created under law by the State of California, USA. Therefore, it must abide by local laws, and answers to the US judicial system. However, ICANN is also a multi-stakeholder partnership of people from all over the world all with the mission of keeping the Internet secure, stable and interoperable.
Specifically-ICANN has a coordination role for the Internet’s naming system, through the domain name system (DNS) AKA “The address book” of the Internet. This is a system designed to make the Internet accessible to everybody.
Technically, this work is being done by Root servers (more than 200 of them now) which all store a copy of the same file. This acts as the main index to the Internet’s address book. It lists an address for each top-level domain (.com, .gov, .org, se, .nl, etc) where that registry’s own address book can be found.
During ICANN, a new episode of “The Blacklist: Redemption” – an American crime thriller TV series- “The Seven Keys.” Though fictional, this show brought up a very contemporary problem for the Internet. It’s important to understand, what is fact and what is fiction, about these keys to the Internet.
The ‘keys,’ relate to single part of the Internet – the secure mechanism for authenticating data in the domain name system -DNSSEC. This is based on a hierarchy of cryptographic keys, starting at the root of the DNS. These cryptographic keys are managed by ICANN.
DNSSEC was designed to protect applications (and individual users), from using fake or manipulated DNS queries, that could potentially route users to fake web portals to steal identities, information, or money. Currently, all answers from DNSSEC protected zones are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (i.e. unmodified and complete), to the information published by the zone owner – and served on an authorized DNS server.
But lets review some statistics to understand the real impact of this safer, DNS technology. According to Internet Society data, about 90% of Top-Level Domains (TLDs like .com, .gov) and 50% of country-code TLDs (TLDs like .nl, .ua, .se) zones are signed. But for Second-Level Domains (SLDs), the results are different: with over 2.5 million .nl domains approximately only 45% are signed.
90% of measured zones in .gov, over 50% of .cz domains, 25% of .br domains- are signed, whereas only about 0.5% of the zones in .com are signed. Therefore, we see that DNSSEC is wildly distributed, among domain registry operators, but is highly undermanned by an overwhelming majority of customers. The only exception being government sites, where technology is in their favor. Why? Because very often, government portals are targets for DDoS and other hacking activities.
DNSSEC does not necessarily provide privacy, because all DNSSEC responses are authenticated (signed with DS), but not encrypted. DNSSEC does not protect against DDoS attacks directly. Though it indirectly provides some benefits, by d-signature inspection.
But this still allows the use of potentially untrustworthy parties.
It is extremely important that we see attempts to establish “Chains of Trust” by ICANN, and setting up “Trust anchors.” To confirm that a DNS response is accurate, we have to verify at least one key or DS record that matches sources other than the DNS. These “trust anchors,” are typically obtained with the OS, or via some other trusted source.
Root anchors were first published on 15 July 2010 by ICANN. Vinton “Father of Internet” Cerf said about this event: “I would predict, that although we started out putting this system together to assure that the domain name lookups return valid Internet addresses… in the long run this hierarchical structure of trust will be applied to a number of other functions that require strong authentication. And so you will have seen a new major milestone in the internet story.”
So-what exactly did the “Father of Internet,” try to predict?
In general, an authentication chain is a series of linked DNS-signed records that begins with a trust anchor to the trustworthy name server for the domain in query. Without a complete authentication chain, an answer to a DNS lookup cannot be securely verified. That is why ICANN has created its own CA – and generated a “key of keys,” to sign domain zone keys (which are widely self-signed now).
Established by ICANN the, “Chain of trust” can potentially find new applied solutions. Especially when user identification and authorization, is needed i.e. when you need to conduct financial transactions, vote in an election, or sign an e-petition to government. Some institutions are interested in making their communication with clients more secure. Therefore they pay more than 1 000 USD for a 256-bit long string.
I am positive about EV SSL certificates. It is logical that we are also interested in DNSSEC to guarantee that a client will not visit a fake copy of their site. Moreover, because of potential fraud prevention, DNS can be a target for DNS DDoS and in some cases DNSSEC. The qualified client DS certificates feature, can became the model of new business, in the fast-growing market of cybersecurity.
DNSSEC issues where discussed during numerous sessions at ICANN 58. ICANN CTO David Conrad announced the launch of “Key Signing Key” (KSK) Testing Platform for the KSK Rollover.
Internet service providers, network operators and others who have enabled DNSSEC validation must update their systems with the new KSK by the following two methods:
1) An operator can configure a new trust anchor manually, by obtaining the new root zone KSK from the iana.org website;
2) An operator can enable a feature available in many validating resolvers, that automatically detects and configures a new root zone KSK as a trust anchor, in which case they need take no action.
The KSK has been widely distributed and configured by every operator performing DNSSEC validation. If the validating resolvers using DNSSEC do not have a new key when KSK is utilized, end users relying on those resolvers will encounter errors and be unable to access the Internet.
One of the most appealing sessions on DNSSEC during ICANN 58 was on crypto algorithms development in DNSSEC. ECDSA was standardised for DNSSEC in 2012 (RFC 6605), but was no use of it before 2015. In 2015, CloudFlare announced the service of a “Universal DNSSEC,” withon-the-ﬂy DNSSEC signing using ECDSA. In 2016, PowerDNS made ECDSA a default algorithm. Currently, ECDSA (p256-SHA256) among algorithm distribution in .com gained 15% of the grand total, and RSA (SHA1-NSEC3) 70%.
NIST recommended a switch to ECC and larger RSA keys years ago, but for now this recommendation is not yet acknowledged: 8% of .gov domains use 1024-bit RSA; six .gov domains still use 512-bit RSA and almost 50% of .gov domains use SHA1 hashing in DNSSEC, against NIST recommendations from 2015.
But there is more room for improving efficiency and cryptographic strength by using EdDSA, which has recently been standardised for use in DNSSEC (RFC 8080). For now, EdDSA support is (virtually) non-existent in software. But there are good reasons to push for EdDSA support: it is much faster; it’s keys require only half the space of an equivalent ECDSA key in a DNSKEY record – and EdDSA has better security properties.
But there is lot of room left to develop DNSSEC, as queries are signed but not encrypted. The introduction of some kind of Transport Layer Security (TLS), for DNS queries in encrypted packages, is highly expected.
To summarize my observations about DNSSEC and current trends, I suggest such the below formula for a “Safer Internet.”
This will probably be adopted as standard in the next five to ten years: Safer Internet = (TSL(HTTPS) ∩ (TLS ( DNSsec)))* EdDS