Vantages Applications

DNSKEY Trust-Anchor Learning and Verification
D-Sync (Parent-Child DS / DNSKEY Synchronization)

DNSKEY Trust-Anchor Learning and Verification
Tutorial

Vantages's DNSKEY Learning and Verification application is an infrastructureless service (it does not need an a priori infrastructure, no 3rd party service required, all done by users and those that they trust) that acts as a cryptographic key lookup mechanism. It can currently act like a DNSSEC Distributed Trust Anchor Repository (TAR). The DNSKEY application uses the verification properties of DNSSEC's public data to verify DNSKEYs for DNS resolvers, and has the following basic building blocks:

Each user of the Vantages system runs a daemon that is a single Vantage point,
COTs are implemented as a set of peer-to-peer Vantages that form overlapping communities of independent friends,
It uses an expressive verification taxonomy for DNSKEYs,
It has the ability to take data from a variety of sources and protocols,
It has the transparency to show how unprocessed data is converted into usable DNSKEYs,

Vantages' Community of Trust (COT) concept is defined as a set of Vantages that can act as friends and cooperate to verify public data. However, clearly not all parties will want to communicate with or trust each other. In fact, it is likely that there may be overlapping networks of people interested in trusting each other. Trust is not transitive and a user may not trust the friends of their trusted friends (Figure 1). Furthermore, the number of friends describes how many paths can be used to reach data, and in a real system this will clearly not approach infinity.
In addition, DNS resolvers do not necessarily query the same set of DNS zones, and therefore do not all look at the same values. It is unreasonable for resolvers that belong to different authorities prompt each other to perform additional DNS queries. Further, when different resolvers do query the same zones, they will not necessarily do so at the same time. Thus, a system must consider issues of data-overlap and the rate at which data may have changed.
Another relevant issue that arises for DNSSEC is that some data owners serve their DNSKEYs over multiple protocols. For example, there is a growing practice for zones to serve their keys on web pages in addition to serving them from DNS name servers. This allows data to be checked for consistency across different types of protocols as well as just network vantages.

Figure 1: Overlapping communities of trust

Finally, it is important for Vantages to be sure that data they have received from each other was not spoofed. When a vantage considers an observation from another vantage in the COT, it must be certain that the data has not been spoofed. Moreover, to meet the Public Data requirement of non-repudiation Vantages must ensure that once a Vantage has observed data it must that any other vantage can always prove that observed data existed (even if it is no longer served).
Multiple Vantage Points:
After processing data into DNSKEYs, Vantage daemons check the consistency of the keys with their list of trusted friends (remote Vantage daemons). Having multiple views (or vantages) of the same DNSKEY is the primary mechanism that Vantages uses to do its verification. The result is that having a trusted set of friends at different points in the network fulfills the Public Data requirement of having multiple paths. The actual mechanism to spoof DNS resolvers has been extensively discussed in mailing lists, on websites and even in the academic literature and is beyond the scope of this page. The enlistment of community members as pollers is a notable contrast to previous distributed key verification systems like SecSpider in which users must rely on a 3^rd party infrastructure. The importance of this contrast is that, unlike other approaches, Vantages' protections do not have the prerequisite of a ``trusted'' 3^rd party. Thus, Vantages' trust model is dictated by its operator's decision of whom she will configure as friends.
Vantages is both flexible and easily configurable and its design goal is to let operators use real-world trust when deciding who to configure as friends. This is a notable contrast to self-organizing peer-to-peer networks like FreeNet, Gnutella, KaZaa, BitTorrent. The success of these networks comes (in large part) because of their ability to scale and self-organize. However, because of their anonymous nature, the peers in these networks can be arbitrarily malicious to each other. This can result in peers sending erroneous data (called pollution) or even attacking each other. This has not abated their success because use rs rarely trust these open networks to provide them with important transactions like banking or e-commerce. By contrast, DNS is an integral part of essentially all Internet activity, and allowing anonymous peers to influence security decisions should be a decision left to each operational group, rather than mandated by a system design. Thus, Vantages makes the decision of whom its daemons can become friends a user-specific attribute. However, this is not to imply that identifying friends is challenging. Many DNS zone operators already do this when following operational best-practices and setting up secondary name servers in remote networks. Additionally, many operators meet each other at operational conference s such as NANOG and RIPE. The operational community is rife with opportunities for operators to aid each other in such a lightweight operation and we anticipate that sites like SecSpider will act as open Vantages friends for operators who want to use them.
Verification:
When querying a friend, Vantages does not expect that the remote daemon will necessarily have previously queried for the DNSKEYs in question. In fact, the opposite is often the case, or if the friend does have the data it may be too old to rely on. In these cases, Vantages can still proceed. Stale data can often be recognized by using the existing inception and expiration dates on DNSKEYs' signatures.
The definition of Public Data uses the notion that as the number of paths approaches infinity, the consistency reaches its absolute maxima, and data can then be verified. As a real system of friends, Vantages will not approach this number of paths. Therefore the system uses available evidence and a classification scheme called CPUC to classify DNSKEYs into one of four exclusive states: The first state is

Confirmed, and it indicates that no conflicting values for the DNSKEY were seen over any protocol or from any friend, and at least a threshold number (n) of friends have also seen the same value for the key. The second state is
Provisional, and it means that a key was seen by other friends, but the number of friends is less than the configured threshold of n. The third state is
Unknown, and these are keys which Vantages can provide no protection for because they have not been seen by any friends. Finally, the last state is
Conflict, and this state is an alert that either a conflicting set of keys were seen over different protocols or from any friend. The main benefit of the CPUC scheme is that it is an evidence-based verification scheme that lets end-users specify their own local policy of which states qualify a key as ``verified.''

Diverse Protocols:
Vantages collects each of its DNSKEYs via any combination of DNS queries, HTTP or HTTPS requests. This list of protocols was chosen based on the current DNSSEC operational practices. key rollovers. It has become an operational convention, when constructing a trust-anchors file, for operators to augment their DNS lookups with DNSKEYs t hat are served from zones' web pages (where available). Vantages takes this a step further and automates this process. Thus, each Vantage daemon may either collect its DNSKEYs from just a single source, or from multiple sources. In order to allow operators to specify data sources in a general way, data sources are specified via standard URLs. In addition to just Public Data such as DNS and HTTP, users can advertise keys that they own via local attestations (specifying a local non-public data source). This allows zone owners to specify which DNSKEYs they are authorities for so that their friends (who already trust the owners as Vantage-friends) can bootstrap each others' DNSKEYs.
Data Provenance:
Vantages implements and shares the data provenance of its DNSKEYs with friends so that the origin source that friends have learned keys from is transparent to users. This level of transparency allows operators to accept or reject each others' Vantage data based on its original source, and/or scraping. For example, a Vantage operator may decide not to trust anyone's manual attestations or may blacklist certain TARs. This configuration simply uses the provenance of all remote key looks to prune keys from those data sources. This is depicted in Figure 2.

Figure 2: Data provenance from multiple sources.

System Implementation
The DNSKEY verification application is implemented as a community of individual daemons (vantaged) that each operational group runs on one of their local servers. These daemons accept data sources that operators want to poll (such as web pages), and allow operators to configure a list of friends that they would like their daemon to confer with when verifying keys. The main configuration interface to Vantages is through a web-based configuration dashboard that is served from an embedded web server, which runs on a configurable port, and can optionally be password protected (Figure 2).

Figure 2: The main dashboard of Vantages' DNSKEY verification application
The vantaged daemon is written in C++, and is open source (available for download from here). The data it gathers as well as its meta-data are stored in a local SQLite database. When setting up a Vantage daemon, the operator must specify a GnuPG key to use as a signing key by the daemon.
Operators can add data sources to be polled by submitting URLs through the administrative web dashboard. In addition, Vantages can be configured to use libpcap to automatically learn and poll DNS sources of zones that the host machine sees DNS traffic to. This option is useful when Vantages is deployed on a machine that hosts a recursive resolver.
Configuring vantaged with friends involves bootstrapping the local daemon with the public PGP key from a friend's daemon, the HTTP URL that their daemon listens on, and optionally an HTTP password. This allows vantaged to automatically connect to, authenticate with (if a password is specified), and begin verifying data with that friend. The data is returned with PGP signatures, and the friend's PGP key can be used to verify its origin authenticity.
The default behavior for the daemon is to poll all of the configured data sources at fixed intervals (though polling is randomized to avoid pattern detection). The polling behavior has been optimized for speed so that many thousands of DNS zones can be polled in minutes. This allows the daemon to (if desired) maintain a very fresh view of the sources it tracks.
After each polling cycle, the daemon contacts all of its configured friends with the list of zone names it has just queried. Friends then respond with the DNSKEY values they have seen, and when the last time they saw them. With the responses from friends, vantaged classifies each of keys with its CPUC taxonomy.

D-Sync (Parent-Child DS / DNSKEY Synchronization)
Tutorial

Vantages's D-Sync application is an automated solution to managing DNSKEYs across domain boundaries. Its primary function is to monitor the relationship between a set of DNSKEYs for a given domain, and the corresponding DS records at the parent domain. D-Sync generates simple alert messages during a key rollover, notifying administrators when to change a key change has been detected, when to change a DS record, when it is safe to remove the old DNSKEY from the keyset, and when the domains are back in-sync.
D-Sync uses a simple finite state engine and normal DNS queries to determine the synchronization state of a zone. It does not require any special access to private keys or any other form of internal data, and is agnostic of where it is run. As such, D-Sync can be employed at the parent domain, at the domain itself, or at a third-party monitoring location. All that is required to begin monitoring a zone with D-Sync is a valid public key.

D-Sync state engine

(Contact us at tools@netsec.colostate.edu)

DNSKEY Trust-Anchor Learning and Verification Tutorial
Vantages's DNSKEY Learning and Verification application is an infrastructureless service (it does not need an a priori infrastructure, no 3rd party service required, all done by users and those that they trust) that acts as a cryptographic key lookup mechanism. It can currently act like a DNSSEC Distributed Trust Anchor Repository (TAR). The DNSKEY application uses the verification properties of DNSSEC's public data to verify `DNSKEY`s for DNS resolvers, and has the following basic building blocks: Each user of the Vantages system runs a daemon that is a single Vantage point, COTs are implemented as a set of peer-to-peer Vantages that form overlapping communities of independent friends, It uses an expressive verification taxonomy for `DNSKEY`s, It has the ability to take data from a variety of sources and protocols, It has the transparency to show how unprocessed data is converted into usable `DNSKEY`s,
Vantages' Community of Trust (COT) concept is defined as a set of Vantages that can act as friends and cooperate to verify public data. However, clearly not all parties will want to communicate with or trust each other. In fact, it is likely that there may be overlapping networks of people interested in trusting each other. Trust is not transitive and a user may not trust the friends of their trusted friends (Figure 1). Furthermore, the number of friends describes how many paths can be used to reach data, and in a real system this will clearly not approach infinity. In addition, DNS resolvers do not necessarily query the same set of DNS zones, and therefore do not all look at the same values. It is unreasonable for resolvers that belong to different authorities prompt each other to perform additional DNS queries. Further, when different resolvers do query the same zones, they will not necessarily do so at the same time. Thus, a system must consider issues of data-overlap and the rate at which data may have changed. Another relevant issue that arises for DNSSEC is that some data owners serve their `DNSKEY`s over multiple protocols. For example, there is a growing practice for zones to serve their keys on web pages in addition to serving them from DNS name servers. This allows data to be checked for consistency across different types of protocols as well as just network vantages.	Figure 1: Overlapping communities of trust
Finally, it is important for Vantages to be sure that data they have received from each other was not spoofed. When a vantage considers an observation from another vantage in the COT, it must be certain that the data has not been spoofed. Moreover, to meet the Public Data requirement of non-repudiation Vantages must ensure that once a Vantage has observed data it must that any other vantage can always prove that observed data existed (even if it is no longer served). Multiple Vantage Points: After processing data into `DNSKEYs`, Vantage daemons check the consistency of the keys with their list of trusted friends (remote Vantage daemons). Having multiple views (or vantages) of the same `DNSKEY` is the primary mechanism that Vantages uses to do its verification. The result is that having a trusted set of friends at different points in the network fulfills the Public Data requirement of having multiple paths. The actual mechanism to spoof DNS resolvers has been extensively discussed in mailing lists, on websites and even in the academic literature and is beyond the scope of this page. The enlistment of community members as pollers is a notable contrast to previous distributed key verification systems like SecSpider in which users must rely on a 3^rd party infrastructure. The importance of this contrast is that, unlike other approaches, Vantages' protections do not have the prerequisite of a ``trusted'' 3^rd party. Thus, Vantages' trust model is dictated by its operator's decision of whom she will configure as friends. Vantages is both flexible and easily configurable and its design goal is to let operators use real-world trust when deciding who to configure as friends. This is a notable contrast to self-organizing peer-to-peer networks like FreeNet, Gnutella, KaZaa, BitTorrent. The success of these networks comes (in large part) because of their ability to scale and self-organize. However, because of their anonymous nature, the peers in these networks can be arbitrarily malicious to each other. This can result in peers sending erroneous data (called pollution) or even attacking each other. This has not abated their success because use rs rarely trust these open networks to provide them with important transactions like banking or e-commerce. By contrast, DNS is an integral part of essentially all Internet activity, and allowing anonymous peers to influence security decisions should be a decision left to each operational group, rather than mandated by a system design. Thus, Vantages makes the decision of whom its daemons can become friends a user-specific attribute. However, this is not to imply that identifying friends is challenging. Many DNS zone operators already do this when following operational best-practices and setting up secondary name servers in remote networks. Additionally, many operators meet each other at operational conference s such as NANOG and RIPE. The operational community is rife with opportunities for operators to aid each other in such a lightweight operation and we anticipate that sites like SecSpider will act as open Vantages friends for operators who want to use them. Verification: When querying a friend, Vantages does not expect that the remote daemon will necessarily have previously queried for the `DNSKEY`s in question. In fact, the opposite is often the case, or if the friend does have the data it may be too old to rely on. In these cases, Vantages can still proceed. Stale data can often be recognized by using the existing inception and expiration dates on `DNSKEY`s' signatures. The definition of Public Data uses the notion that as the number of paths approaches infinity, the consistency reaches its absolute maxima, and data can then be verified. As a real system of friends, Vantages will not approach this number of paths. Therefore the system uses available evidence and a classification scheme called CPUC to classify `DNSKEY`s into one of four exclusive states: The first state is
Confirmed, and it indicates that no conflicting values for the `DNSKEY` were seen over any protocol or from any friend, and at least a threshold number (n) of friends have also seen the same value for the key. The second state is Provisional, and it means that a key was seen by other friends, but the number of friends is less than the configured threshold of n. The third state is Unknown, and these are keys which Vantages can provide no protection for because they have not been seen by any friends. Finally, the last state is Conflict, and this state is an alert that either a conflicting set of keys were seen over different protocols or from any friend. The main benefit of the CPUC scheme is that it is an evidence-based verification scheme that lets end-users specify their own local policy of which states qualify a key as ``verified.'' Diverse Protocols: Vantages collects each of its `DNSKEY`s via any combination of DNS queries, HTTP or HTTPS requests. This list of protocols was chosen based on the current DNSSEC operational practices. key rollovers. It has become an operational convention, when constructing a trust-anchors file, for operators to augment their DNS lookups with `DNSKEY`s t hat are served from zones' web pages (where available). Vantages takes this a step further and automates this process. Thus, each Vantage daemon may either collect its `DNSKEY`s from just a single source, or from multiple sources. In order to allow operators to specify data sources in a general way, data sources are specified via standard URLs. In addition to just Public Data such as DNS and HTTP, users can advertise keys that they own via local attestations (specifying a local non-public data source). This allows zone owners to specify which `DNSKEY`s they are authorities for so that their friends (who already trust the owners as Vantage-friends) can bootstrap each others' `DNSKEY`s. Data Provenance: Vantages implements and shares the data provenance of its `DNSKEY`s with friends so that the origin source that friends have learned keys from is transparent to users. This level of transparency allows operators to accept or reject each others' Vantage data based on its original source, and/or scraping. For example, a Vantage operator may decide not to trust anyone's manual attestations or may blacklist certain TARs. This configuration simply uses the provenance of all remote key looks to prune keys from those data sources. This is depicted in Figure 2.	Figure 2: Data provenance from multiple sources.
System Implementation The DNSKEY verification application is implemented as a community of individual daemons (`vantaged`) that each operational group runs on one of their local servers. These daemons accept data sources that operators want to poll (such as web pages), and allow operators to configure a list of friends that they would like their daemon to confer with when verifying keys. The main configuration interface to Vantages is through a web-based configuration dashboard that is served from an embedded web server, which runs on a configurable port, and can optionally be password protected (Figure 2). Figure 2: The main dashboard of Vantages' DNSKEY verification application The `vantaged` daemon is written in C++, and is open source (available for download from here). The data it gathers as well as its meta-data are stored in a local SQLite database. When setting up a Vantage daemon, the operator must specify a GnuPG key to use as a signing key by the daemon. Operators can add data sources to be polled by submitting URLs through the administrative web dashboard. In addition, Vantages can be configured to use `libpcap` to automatically learn and poll DNS sources of zones that the host machine sees DNS traffic to. This option is useful when Vantages is deployed on a machine that hosts a recursive resolver. Configuring `vantaged` with friends involves bootstrapping the local daemon with the public PGP key from a friend's daemon, the HTTP URL that their daemon listens on, and optionally an HTTP password. This allows `vantaged` to automatically connect to, authenticate with (if a password is specified), and begin verifying data with that friend. The data is returned with PGP signatures, and the friend's PGP key can be used to verify its origin authenticity. The default behavior for the daemon is to poll all of the configured data sources at fixed intervals (though polling is randomized to avoid pattern detection). The polling behavior has been optimized for speed so that many thousands of DNS zones can be polled in minutes. This allows the daemon to (if desired) maintain a very fresh view of the sources it tracks. After each polling cycle, the daemon contacts all of its configured friends with the list of zone names it has just queried. Friends then respond with the `DNSKEY` values they have seen, and when the last time they saw them. With the responses from friends, `vantaged` classifies each of keys with its CPUC taxonomy.

D-Sync (Parent-Child DS / DNSKEY Synchronization) Tutorial
Vantages's D-Sync application is an automated solution to managing `DNSKEYs` across domain boundaries. Its primary function is to monitor the relationship between a set of `DNSKEYs` for a given domain, and the corresponding `DS` records at the parent domain. D-Sync generates simple alert messages during a key rollover, notifying administrators when to change a key change has been detected, when to change a `DS` record, when it is safe to remove the old `DNSKEY` from the keyset, and when the domains are back in-sync. D-Sync uses a simple finite state engine and normal DNS queries to determine the synchronization state of a zone. It does not require any special access to private keys or any other form of internal data, and is agnostic of where it is run. As such, D-Sync can be employed at the parent domain, at the domain itself, or at a third-party monitoring location. All that is required to begin monitoring a zone with D-Sync is a valid public key.	D-Sync state engine