Skip to main content

Ways of Trusting Internet Identifiers

Recent news that Google's Chrome browser is going to trust Symantec-issued transport layer security (TLS) certificates less than those from other certificate authorities (CAs) has reignited debates about how trust is expressed to Internet users. Certificates for TLS are used to trust the security of websites, but the Web Public Key Infrastructure (PKI) relies on the fact that there are well over 100 CAs, any of which can issue certificates to authenticate any website. The challenge is that to be trustworthy, someone has to specify both the rules that govern how all CAs as well as how to remove CAs that fail to live up to those rules.

In the past two decades, the browser vendors such as Mozilla (Firefox), Google (Chrome), Apple (Safari) and Microsoft (Internet Explorer and Edge) have had to become the arbiters of trustworthiness for the CAs. Each browser has its own policies for how to deal with CAs that appear to not be meeting the requirements for trustworthiness based on the way the browser vendor wants to protect its users. The major browser vendors and a few dozen CAs are members of the CA/Browser Forum. This group creates its “baseline requirements” that describe the policies CAs should follow, but it does not police its members. Thus, the browser vendors need to do their own enforcement of the trustworthiness of CAs. That can lead to enforcement actions like Google's restrictions on Symantec-issued certificates and, earlier, on WoSign-issued certificates, Diginotar-issued certificates and others.

Is DNSSEC the Answer?

When these debates come up, people often bring up securing the Domain Name System (DNS) through DNS Security Extensions (DNSSEC) as a potential alternative or adjunct to the existing X.509-based Web PKI. At a high level, the Web PKI protects the integrity of the content of web pages, while DNSSEC protects the integrity of the DNS data that can lead you to those web pages. But the two systems have fundamentally different models for how their data is trusted. One major difference between the two systems is that the Web PKI relies on a list of over a hundred organizations that all need to be fully trusted, while DNSSEC has a single global trust anchor. Another significant difference is that the authentication in the Web PKI is done by browsers that the user chooses, while DNSSEC authentication is done by the resolvers that the user's computer chooses to use.

The single global trust anchor brings related advantages to DNSSEC. The Internet community demands greater transparency in how trust is handled in the DNS than it has in the Web PKI, and ICANN has responded by having an extremely open, transparent and accountable process. Trusted community representatives play an active role in the maintenance of the cryptographic keys, participating in ceremonies that people can watch either live or via recordings. Technical communities help shape the processes that govern the chain of trust for DNSSEC, including major contributions to the process that ICANN is using to update (or roll) the root zone key signing key (called the KSK rollover).

The Web PKI is not going away anytime soon, but it is likely that the way that browsers interact with the CAs will evolve. In fact, there are moves underway to make the Web PKI interact better with DNSSEC through DNS-based Authentication of Named Entities (DANE), which relies on DNSSEC. The TLS Working Group in the Internet Engineering Task Force (IETF) is working on allowing TLS clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. When finished, this could lead to an interesting hybrid trust model for browsers that leverages the best of the DNSSEC trust model.

CAs Will Evolve

Given the scale of the Web PKI and the number of little-known actors at its core, it isn’t surprising that Internet users keep asking the question of how to ensure trust in the DNS. Browser vendors will take even more actions to improve the security for their users. As DNSSEC becomes more widely deployed, it seems likely that using DNSSEC to secure the DNS will contribute even more to establishing trust that enables Internet users to communicate securely.


    Dao My Linh  01:56 UTC on 12 April 2017

    That's true. It seems that it is the beginning of a revolution in information security on the internet. Websites that don’t use the https protocol will receive warnings on google chrome. For other browsers like FireFox, Safari, Opera, etc, this has not been done yet but I believe it's just a matter of time.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."