|
||
|
||
The recent news that .uk, .arpa and .org may sign their zones sometime this year is indeed good 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 zones. 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 new RRs.
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 mail.example.com would be obtained by a security-aware resolver through a query for a CERT RR for mail.example.com similarly for www, ftp or any other host or service.
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 or rollover of keys due to expiry or 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.
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byRadix
Sponsored byVerisign
A World-Renowned Source for Internet Developments. Serving Since 2002.
As someone that was one of the early designers of DNSSEC, I’d like to address some points. I’m quoting only relevant parts of the original post.
Mostly I’m saying - we did try that, we failed, but if anyone wants to try again, I’ll cheer you on knowing you’re playing an underdog role in this game!
> A number of observers have noted that if the above conditions are
> true then we can reliably place valuable or sensitive data in
> secured zones. Unfortunately the same observers normally stop at
> that point.
Well, we didn’t stop, we did quite a bit of work towards that goal but gave up when it proved to be unacceptable. In December of 2001 there were a number of documents in the IETF suggesting the use of DNSSEC as a PKI. This lead to a March 2002 BoF session in which the security area gurus determined that if the DNS had become the defacto PKI for the Internet, the result would be “too many eggs in that basket.” The fear was that it could take as little as a single currupt tree to open up vulerabilities in many resources.
This was the SIKED BoF. It met once, resulted in one spinoff group which produced the SSH key fingreprint record, but otherwise the effort to leverage DNSSEC as a PKI or key distribution mechanism folded.
> 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..
I agree that this sounds promising. But from experience, it didn’t work out. We tried, unfortunately I can’t point you to a document that gives details (as the IETF wasn’t too good then at documenting the failed ideas).
(Note we “*explicitly* disavowed” in past tense!)
> 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.
This is the sentence that launched my desire to reply. The TTLs are not at all capable of fulfilling what CRLs do. For one, TTLs are relative time. CRLs use a fixed time basis. TTLs can be manipulated easily. You can “replay” DNS records (inside the signature validity period), only a CRL can really stop the effectiveness of a Certificate.
Then there is the trust model. Certificates have an entirely different operational model for trust than DNSSEC and this is why a DNSSEC signed CERT RR has a reason to exist. I am tempted to go into too much detail here. I don’t mean to lecture on X.509…
> 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
I remember doing that in a prototype in December 2000, yes, we’ve played with that idea already.
> ensuring the integrity of data. Why not simply use a KEY RR for
> domain based applications? This has the advantage of simplifying the
I recall writing a draft suggesting that in the summer of 2001. The stumbling block is that it would mean that the DNS admin ultimately had the keys to everything - a host administrator could not compartmentalize their security. (Even though the DNS admin lacked the private key, the admin could disrupt service to the host by omitting the key from the zone.)
> So we come finally to the trust process. Adding a signed zone to a
Think about this - if your host keys are put into DNS and then signed, you are placing faith in your local DNS admin. Okay, not too bad. But if you start climbing the tree you will see that you have to trust the TLD admin (and maybe a registrar/reseller), and the root zone managers to always have things signed correctly. (You could argue that if they mess up, the problem is bigger than just the DNS!)
Another couple of data-points:
* Me and Jakob Schlyter did a draft along those lines a couple of years ago: draft-schlyter-pkix-dns-02.txt.
* At a recent meeting about DNSSEC in .edu at an Internet2 member meeting I proposed the idea that the way to sell DNSSEC in .edu is to use the DNSSEC trust to bootstrap things like the InCommon Federation.
I couldn’t resist checking the history of DNSSEC to see what evidence we had of our considering DNSSEC as a key distribution mechanism. I pulled this from the early, early email archive of the DNSSEC WG (1994?-1999) of the IETF.
This doesn’t give a reason that “it won’t work” but it shows that it has been considered (15 years ago!) and even then it was starting to run into doubts.
Date: Mon, 1 Nov 1993 12:43:54 -0500
From: Steve Lunt
Message-Id:
<[email protected]>To: .(JavaScript must be enabled to view this email address)
Subject: Re: DNS Security Sub-Working Group
It seems that from this initial charter that several goals/security services
are being confused.
> Unresolved Issues for DNS Security
>
> 2. Insofar as PEM is a technology that provides key management services,
> the DNS could make use of it to distribute certificates. ...
As I understand things, PEM is designed for store-and-forward
environments, and key management defined therein is intended to
support that environment. Perhaps direct use of authentication
mechanisms as defined within the Internet (e.g., Kerberos V5)
which are intended for on-line, peer-to-peer authentication
should be used instead.
> The following subissues are relevant to this discussion.
>
> a. If the DNS is “secure”, could we store/distribute just keys
> in/with it, or do we need certificates?
I see the DNS as being useful in acting as a name service
in support of Kerberos V5 (e.g., realm-to-Kerberos server
mappings, hostname-to-realm name mappings, etc.) and perhaps
for other authentication mechanisms as well.
I don’t think that we need to define yet another authentication
mechanism specifically for a particular application.
> b. If we store certificates, and even large keys, their distribution
> or inclusion in DNS replies may exceed the maximum size allowed.
> Two suggestions have been made. First, we could propose a
> parallen DNS-like server that does not have the limitation.
> Second, we could specify MX-like records that point to “key”
> manager services.
Again, I don’t think the DNS is the place to store this
kind of stuff.
> c. Could SNMP be used to distribute the key/certificates?
Especially not here!
—Steve
Ed - I don’t claim that just any key distribution scheme can be poured into CERT/KEY RRs. However there are properties of how key management is being envisioned in SAML-based identity federation that makes it more likely that DNSSEC might play a role in this case.
Leif Johansson said:
I’m not claiming that DNSSEC can’t play a role. I was one of the chairs of the SIKED BoF which tried to promote the use of DNSSEC to distribute keys of applications. But what I remember the most was the feeling of standing with my back against the conference room partition wishing they had I blindfolded me, bound my hands behind my back and given me a cigarette before I was fired at by the Security Area experts of the IETF for promoting such lunacy.
Okay, that’s not giving a reason why there’s a problem with putting application and other keys into the DNS. It’s just the emotional scar I have from that effort.
Why, after SIKED flamed out, did SSHFP (which was part of SIKED at one time) succeed? Not really sure, but maybe it had to do with SSH having other protection mechanisms. I suppose SSHFP doesn’t completely rely on DNSSEC for it’s security, that SSH has some checks and balances built in - if the key is not as expected (which could happen if DNSSEC were corrupted).
Could other applications put keys into DNS and use DNSSEC? Sure. Have they tried? Yeah, you could say DKIM is doing this (not “keys” pre se, but a DKIM signature which is being inserted before DNSSEC is in play). But nothing (I’d say not even SSHFP) have become mainstream.
Edward Lewis said:
Ed:
Thanks for your comments and for your reminder than some of this ground has been covered before (and from your later comments with painful memories!). A couple of follow-ups to explore the issues further:
First the case I proposed deals with only self-signed CERTs. Third party (CA) signed CERTS will always require CRL/OCSP in the normal way since any remedial action must orginate from the signing (CA) party. In the self-signed case all the remedial actions lie with the domain owner (I’m assuming they sign the CERT) thus removal or replacement of the CERT (or KEY) achieves the same effect with a latency determined by the TTL (say 3 - 60 minutes). This contrasts with the potentially significant latencies involved in CRLs (and some implementations even cache CRLs). While OCSP significantly reduces the latency it does not remove it. Thus while TTLs and CRL time values have different properties I’m not sure that in the self-signed case this is significant.
While I’m not for one minute suggesting that third party CERTs will disappear I am suggesting that the basic trust model of a third party signed CERT and a self-signed CERT in a DNSSEC have a different but equivalent trust model - assuming that the registration process and the chain joining process are secure and trustworthy - hence my final comments in the post.
I would say here that you have to trust someone (or not) in all cases - either a third party CA or DNS admins (in-house or perhaps third party). Is there a difference?
This is a major point - are we placing too much trust in a single system - DNS? On the postive side of using DNSSEC. First due to DNS importance we know from current experience that the sigificant accumulated expertise embodied in the various registries ensures that it is pretty reliable! Second point here is that if there were compromises at some point in the DNSSEC hierarchy the fix is at that level with no ramifications for the lower levels. In the case of CA compromises every CERT is affected thus significant remedial action is required by users.
I don’t want to come across as argumentative on this, but I do want to suggest an answer or two:
Ron Aitchison said:
I think the difference lies in what happens when things go wrong. For a CA once I had to outline a 0.9 version of a Certification Practices Statement, kind of a “here’s what we promise when signing.” DNSSEC lacks that. Being rather uninitiated in the field of law, I assume that if there was a legal dispute, well, this might come into play.
And this is the point where I might be saying something argumentative. I read Ron’s recent posting just after reading COMCAST Domain Name Hacked, particularly “early indications are that someone hacked Comcast’s registrar account”. I also recall an attack a few years back (details fuzzy) that involved a reseller - registrar mis-interaction.
Frankly, it’s a toss up. DNSSEC can be an alternative to a CERT hierarchy (in “backing” a self-signed CERT). Whether it is a good, better or worse, bad alternative is going to depend on how one weighs the pain, anguish and benefits of the two alternatives. In some cases I think DNSSEC could be a better alternative but I have run into people that are more afraid that there are also cases where it is a worse alternative and thus conclude “never!” (Harking back to my comments on wanting to have been bound, blindfolded and cigaretted.)
I don’t think you are argumentative at all - you bring up good points! It is true that DNSSEC lacks the notion of a CP and in certain types of business relationships that may well be an issue. However the recent appearance and growth of promiscuous schemes like OpenID shows that lots of people are willing to trust just about anything. In the light of this I’d say that providing some trust is a lot better than none at all.