25-05-2012, 03:25 PM
Deploying Cryptography in Internet-Scale Systems: A Case Study on DNSSEC
[attachment=23027]
INTRODUCTION
CRYPTOGRAPHIC mechanisms can provide effective means
to secure the Internet, and the DNS Security Extensions
(DNSSEC) [2], [3], [4] are among the first attempts to add
cryptographic protection into one of the Internet’s core
systems (the DNS). The goal of DNSSEC is to add data
integrity and origin authenticity to DNS query replies so that
users can verify that the answers received are indeed
originated from the intended DNS server and have not been
altered. Securing the DNS service not only can defeat
emerging threats like DNS hijacking and cache poisoning
but also may provide a foundation for deploying other
cryptographic-based security applications. Specifically, the
DNS can be used to store and serve the public keys of various
entities. After 12 years of development efforts by IETF, the
DNSSEC standards were finalized in March 2005 and a
number of testbeds, pilot deployments, and services have
been rolled out in the last few years [12], [11], [21], [10], [27].
Domain Name System
All DNS data are stored in core data structure called a
Resource Record (RR), and each RR has an associated
name, class, and type. For example, an IPv4 address for
www.ucla.edu is stored in an RR with name www.ucla.edu,
class IN (Internet), and type A (IPv4 address). The set of all
RRs associated with the same name, class, and type is called
an Resource Record Set (RRset). Since DNS resolvers issue
queries for name, class, and type tuples, they are inherently
querying for RRsets (and not individual RRs). For example,
when a browser queries for hwww.ucla.edu, IN, Ai, the
reply will be the RRset for www.ucla.edu with all of the
IPv4 addresses for that name. Thus, the smallest unit that
can be requested in a query is an RRset, and all DNS actions
including cryptographic signatures discussed later, apply to
RRsets rather than individual RRs.
DNS Security Extensions
DNS was designed without security as a central concern,
and a variety of possible attacks against DNS have been
identified [6]. An attacker can exploit these vulnerabilities to
inject spoofed DNS data and redirect user traffic (e.g., Web
browsing) to incorrect and often malicious sites, leading to
various denial of service and/or security breaches. A
detailed threat analysis for DNS can be found in [5]. To
defend against these threats, the DNS Security Extensions is
designed to achieve two security goals: data integrity and
origin authenticity. DNSSEC uses public-key cryptography
(RSA, for example) to enable each zone to prove the
authenticity and integrity of its DNS data. To do so, each
zone creates a public-private key pair, stores the public key
in a new RR type called DNSKEY RR, signs its data (in units
of RRsets) using the private key, and stores the signatures at
the authoritative servers in another new type of RRs, called
RRSIG. Whenever a DNSSEC-enabled server returns an
RRset, it also returns the companion signature.
Scaling
DNSSEC authenticates a zone’s public key by verifying a
corresponding signature from its parent zone. Throughout
the rest of this paper, we refer to this signature simply as
the parent’s signature. The choice of where to store this
signature has no impact on its cryptographic security.
Following the convention of storing the data and its
associated signatures in the same place, the first DNSSEC
specifications [9], [8] store both a zone’s public key and its
parent’s signature in the (child) zone.
DESIGN ISSUES WITH A HIERARCHICAL PKI
As we described in the previous section, DNSSEC builds a
Public-Key Infrastructure by leveraging the existing DNS
delegation hierarchy. Specifically, each zone signs the
public keys of all its children zones. However, this
seemingly simple PKI design ran into unforeseen problems
when it was implemented and started to be deployed. In
this section, we show four specific examples of the
problems encountered in practice: scalability, handling data
that cross administrative boundaries, coordination across
these boundaries, and incremental deployability.
Boundary Crossing: Unsigned DNS Data
In an ideal cryptographic design, all data should be signed
to assure authenticity and integrity. When applying
cryptographic protection to a distributed system, however,
new issues arise due to disjoint ownership of the data.
Because DNS is a distributed database that is managed
by different administrative domains, it provides a strict
definition of data ownership. Each RRset belongs to one,
and only one, zone, and each zone signs all its authoritative
data, including the DS RRs from all its children
zones. However, as we described in Section 2, the NS RRs
and glue A RRs of each zone are stored in both the local
zone and the parent zone so that DNS queries can perform
a top-down lookup to find the intended server.
Cross-Domain Coordination
As we discussed earlier, DNS maintains its name delegation
chains through coordinating NS and glue A records between
parent and child zones. Any changes made to these records
by a child zone must be promptly propagated to the parent.
However, because this coordination is done by human
operators and human actions are prone to errors, a recent
measurement study [26] shows that at least 15 percent of the
zones suffer from configuration errors across the child and
parent zone boundaries. Nevertheless, DNS can tolerate
such imperfect parent-child coordination through the
redundancy in DNS servers, and DNS name resolutions
can succeed as long as the parent knows at least one correct
authoritative server used by the child zone.
[attachment=23027]
INTRODUCTION
CRYPTOGRAPHIC mechanisms can provide effective means
to secure the Internet, and the DNS Security Extensions
(DNSSEC) [2], [3], [4] are among the first attempts to add
cryptographic protection into one of the Internet’s core
systems (the DNS). The goal of DNSSEC is to add data
integrity and origin authenticity to DNS query replies so that
users can verify that the answers received are indeed
originated from the intended DNS server and have not been
altered. Securing the DNS service not only can defeat
emerging threats like DNS hijacking and cache poisoning
but also may provide a foundation for deploying other
cryptographic-based security applications. Specifically, the
DNS can be used to store and serve the public keys of various
entities. After 12 years of development efforts by IETF, the
DNSSEC standards were finalized in March 2005 and a
number of testbeds, pilot deployments, and services have
been rolled out in the last few years [12], [11], [21], [10], [27].
Domain Name System
All DNS data are stored in core data structure called a
Resource Record (RR), and each RR has an associated
name, class, and type. For example, an IPv4 address for
www.ucla.edu is stored in an RR with name www.ucla.edu,
class IN (Internet), and type A (IPv4 address). The set of all
RRs associated with the same name, class, and type is called
an Resource Record Set (RRset). Since DNS resolvers issue
queries for name, class, and type tuples, they are inherently
querying for RRsets (and not individual RRs). For example,
when a browser queries for hwww.ucla.edu, IN, Ai, the
reply will be the RRset for www.ucla.edu with all of the
IPv4 addresses for that name. Thus, the smallest unit that
can be requested in a query is an RRset, and all DNS actions
including cryptographic signatures discussed later, apply to
RRsets rather than individual RRs.
DNS Security Extensions
DNS was designed without security as a central concern,
and a variety of possible attacks against DNS have been
identified [6]. An attacker can exploit these vulnerabilities to
inject spoofed DNS data and redirect user traffic (e.g., Web
browsing) to incorrect and often malicious sites, leading to
various denial of service and/or security breaches. A
detailed threat analysis for DNS can be found in [5]. To
defend against these threats, the DNS Security Extensions is
designed to achieve two security goals: data integrity and
origin authenticity. DNSSEC uses public-key cryptography
(RSA, for example) to enable each zone to prove the
authenticity and integrity of its DNS data. To do so, each
zone creates a public-private key pair, stores the public key
in a new RR type called DNSKEY RR, signs its data (in units
of RRsets) using the private key, and stores the signatures at
the authoritative servers in another new type of RRs, called
RRSIG. Whenever a DNSSEC-enabled server returns an
RRset, it also returns the companion signature.
Scaling
DNSSEC authenticates a zone’s public key by verifying a
corresponding signature from its parent zone. Throughout
the rest of this paper, we refer to this signature simply as
the parent’s signature. The choice of where to store this
signature has no impact on its cryptographic security.
Following the convention of storing the data and its
associated signatures in the same place, the first DNSSEC
specifications [9], [8] store both a zone’s public key and its
parent’s signature in the (child) zone.
DESIGN ISSUES WITH A HIERARCHICAL PKI
As we described in the previous section, DNSSEC builds a
Public-Key Infrastructure by leveraging the existing DNS
delegation hierarchy. Specifically, each zone signs the
public keys of all its children zones. However, this
seemingly simple PKI design ran into unforeseen problems
when it was implemented and started to be deployed. In
this section, we show four specific examples of the
problems encountered in practice: scalability, handling data
that cross administrative boundaries, coordination across
these boundaries, and incremental deployability.
Boundary Crossing: Unsigned DNS Data
In an ideal cryptographic design, all data should be signed
to assure authenticity and integrity. When applying
cryptographic protection to a distributed system, however,
new issues arise due to disjoint ownership of the data.
Because DNS is a distributed database that is managed
by different administrative domains, it provides a strict
definition of data ownership. Each RRset belongs to one,
and only one, zone, and each zone signs all its authoritative
data, including the DS RRs from all its children
zones. However, as we described in Section 2, the NS RRs
and glue A RRs of each zone are stored in both the local
zone and the parent zone so that DNS queries can perform
a top-down lookup to find the intended server.
Cross-Domain Coordination
As we discussed earlier, DNS maintains its name delegation
chains through coordinating NS and glue A records between
parent and child zones. Any changes made to these records
by a child zone must be promptly propagated to the parent.
However, because this coordination is done by human
operators and human actions are prone to errors, a recent
measurement study [26] shows that at least 15 percent of the
zones suffer from configuration errors across the child and
parent zone boundaries. Nevertheless, DNS can tolerate
such imperfect parent-child coordination through the
redundancy in DNS servers, and DNS name resolutions
can succeed as long as the parent knows at least one correct
authoritative server used by the child zone.