DNSSEC Adds Value?

Also published in www.circleid.com May 26th 2008.

The recent suggestion that .uk, .arpa and .org may sign their zones sometime this year is interesting news. Each domain is highly significant: .uk would be the first of the big ccTLDs to deploy DNSSEC joining .se, .pr, .br and .bg and many others in various states of experimentation; .org would be the first of the gTLDs; and .arpa, building on the work already done by RIPE, would put operational DNSSEC experience into IANA - an essential precursor to signing the root. As the DNSSEC registry infrastructure moves inexorably forward - primarily driven by top level pressure and considerations of National Interest - it now behoves us to clearly articulate the benefits of DNSSEC to domain owners and registrars. In particular I want to focus on the vast majority of us to whom cold, hard cash is important and parting with it requires as a minimum tangible benefits or, in extreme cases, surgical intervention.

Let me be clear at the outset that I'm assuming an end-to-end DNSSEC enabled Internet. In such an environment a signed authoritative zone communicates directly or indirectly with a security-aware stub, or full-function, resolver located in the end-entity. Such resolvers and specialized DNSSEC libraries are currently available from the UNBOUND and dnssec-tools projects. Any intermediate caching name servers, while having to be security-aware, simply pass on the RRSIG and any other required RRs obtained from the authoritative source when they see the Checking Disabled (CD) bit in the source query. It is the security-aware resolver at the end-entity which performs the serious work of verification. This end-to-end DNSSEC architecture has the advantage of providing complete security coverage while continuing to take advantage of normal recursive and caching capabilities available within a typical DNS operational environment.

When the signed zone is part of a chain of trust - and assuming the end application is aware of this fact - then DNS data arriving at the application or end-entity in response to a query can be trusted to have originated from the interrogated domain - the authoritative domain source is authenticated - and can be trusted to be a complete and faithful copy of the data sent from the authoritative source. DNSSEC additionally provides proof of non-existence (PNE) which also has some interesting benefits.

A number of observers have noted that if the above conditions are true then we can reliably place valuable or sensitive data in secured zone files. Unfortunately the same observers normally stop at that point.

I'm going to suggest that while the DNSSEC designers explicitly disavowed they were building a PKI the natural consequence of a well implemented DNSSEC infrastructure may, in fact, be a PKI for use with any domain name based application such as secure web access, email, SFTP etc.. If such a PKI does exist then could it be leveraged for the benefit - including pecuniary benefit - of all players? In this context the CERT RR and the humble KEY RR together with its specialized cousins the IPSECKEY and SSHFP RRs are obvious starting points - more imaginative readers may care to consider other existing RR types or even consider new ones.

The CERT RR is simply a method by which an X.509 certificate (other certificate formats are also supported) may be placed in a zone as a blob of base64 encoded data. X.509 certificates are designed to support a wide spectrum of uses ranging from personal electronic signatures to authenticating server communications. As a consequence they are necessarily complex structures with large numbers of optional fields and extensions. Nevertheless X.509 certificates are a viable, extensively used and well established solution.

Trivially an X.509 certificate can be viewed as having two purposes: an envelope structure for the secure distribution of public keys to be used for communication with, or authentication of, some entity and a trust component in which a third party - typically a Certificate Authority (CA) - attests by signing the certificate that the enclosed public key is valid for the designated entity.

Extended Validation (EV) X.509 certificates were developed by a group of respected and responsible Certificate Authorities (CAs) concerned with the growth of what are called typically domain-only certificates. The group created a tightened set of rules over the issuance of EV X.509 certificates. EV certificates are now available and currently supported to a greater (Internet Explorer 7) or lesser (Firefox 3, Opera - pending, Safari - ?) extent by the major browsers. While the EV specification covers a number of topics including CA audit procedures, RFC compliance and enhanced applicant verification it does have three items of specific interest. First, the EV process is limited to server (domain name) certificates at this time. Second, it explicitly requires verification that the applicant owns the domain name that will feature in the resulting certificate (normally the CN RDN of the subject or subjectAltName DN). Third, an enhanced (24x7) Certificate Revocation List (CRL) service is mandated which in most cases means use of the Online Certificate Status Protocol (OCSP) though this is not an explicit requirement.

Given the characteristics of DNSSEC outlined above the first user benefit of DNSSEC may be to accord self-signed (by the domain owner) X.509 certificates originating from signed zones which are part of a chain of trust the same status as externally signed certificates when used for server and email authentication (or any other domain based use) and perhaps, since domain ownership is implicit with DNSSEC, even with a status approaching that of EV certificates. Thus a server certificate for communinication with www.example.com would be obtained by a security-aware resolver through a query for a CERT RR for www.example.com.

A number of issues flow from this. First, do we need CRLs (or OCSP) or does the CERT RR's TTL serve this function - in the case of revokation the domain owner can remove the CERT RR (in which case PNE becomes important) or simply replace the certificate in the case of key compromise or validity period extension and the new CERT RR is re-read naturally on TTL expiry. Second, what is to stop a certificate read by this process covering any arbitrary domain name. Here there are two possible solutions to reduce the scope of the certificate; the end-entity validating software can ignore the CN field of the subject DN entirely and substitute the DNS name from which the CERT RR was obtained; alternatively, while most current X.509 certificates use an X.500 subject format DN ( C=, O=) the IETF X.509 standards (RFC 3280 4.1.2.4) allow the use of RFC 2247's domainComponent (DC=, DC=) format such that by limiting the CN field to a host name or email address the certificate scope can be limited by extracting the DC components, prepending the CN and verifying against the domain name from which the CERT RR was obtained. Finally there is the issue of the trust relationship. The method by which a signed domain joins a trusted chain is critical since the integrity of this process determines the level of trust and consequently the viability of the entire DNSSEC trusted chain. This is true in all cases even if CERT RRs are not being used and is addressed later.

So we have a potential method of using self-signed X.509 certificates provided that all the user pieces are in place. While this alone could have significant benefits by, for example, encouraging widespread use of email signatures due to reduced costs perhaps we can go further.

An X.509 certificate is designed to reliably ensure that the public key obtained by an interested end-entity is indeed the public key to be used when communicating with another end-entity even though the network across which it is being transmitted is itself insecure. As noted DNSSEC achieves the objective of authenticating the source and ensuring the integrity of data. Why not simply use a KEY RR for domain based applications? This has the advantage of simplifying the process, always a good thing when considering security, while maintaining exactly the same level of security and functionality as X.509 - again for domain named based communication and authentication only.

The DNS name under which the KEY RR was obtained is equivalent to the subject (or subjectAltName) DN and could be used for both servers and email addresses. Revocation of keys due to expiry or key compromise is achieved through either removal or replacement of the KEY RR - the latency window would be controlled by the KEY RR's TTL value. CRLs are not required. Public keys obtained via a KEY RR could also be used in TLS connections. The current TLS specifications allow for the use of public keys using what is called an anonymous process (RFC 4346 Section F.1.1.1), such as a KEY RR, but unfortunately the RFC neglects to define an appropriate Cipher Suite value for a key-exchange protocol supporting anonymous RSA - perhaps because it was not thought to be required. Purists may argue that RFC 3445 so limited the KEY RR functionality that its use for this purpose would contravene the standards but a syntactically identical RR with a new type number would fix this problem - though an RR name of PUBKEY may find objections among those who consider alcohol to be the root of all evil.

So we come finally to the trust process. Adding a signed zone to a trusted chain is not a trivial matter. It never was. When a domain owner signals that they wish to join a chain of trust for their TLD (assuming it is signed!) then domain ownership, as well as control of the name servers serving the signed zone must be verifiable and done in a secure - trusted - manner. Arguably the current SSL/TLS secure login methods offered by most registrars may be viewed as fulfilling the trust function but additional registrar functionality is required, for example, to join the TLD chain, to indicate KSK rollover or to quit the TLD chain. These requests would be passed to the registry operator for execution.

Anything less than a secure, verifiable process would negate the integrity of the DNSSEC trusted chain. However if carefully and properly done then not only is DNSSEC chain integrity ensured but perhaps other benefits can be leveraged to the advantage of all players. Albeit with minor changes to some well established mechanisms such as X.509 and TLS.

What is eminently clear is that, as the DNSSEC infrastructure grows inexorably, we cannot continue to view chain joining as a 'stuff happens' procedure rather it must be viewed as integral to the domain registration process.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.