ISC announced a new web-based interface for its DNSSEC Look-aside Validation (DLV) registry, a mechanism to allow domain holders to secure their domain information using the DNSSEC protocol extension to DNS in advance of a signed root or TLD zone.
ISC is introducing DLV and other DNSSEC and secure DNS services at the Government Security (GovSec) Expo and Conference in Washington, D.C. The new interface makes it easier for DNS administrators to join the DLV registry and maintain their data. DLV means that DNS administrators aren't dependent on others to get the full benefit of DNSSEC for their own portion of the name space.
For more information about ISC's DLV registry and DNSSEC services, please visit https://dlv.isc.org/
Posts
About ISC's DLV Registry
ReplyDeleteDLV (DNSSEC Look-aside Validation) is an extension to the DNSSECbis protocol. It is designed to assist in early DNSSEC adoption by simplifying the configuration of recursive servers.
DLV provides an additional entry point (besides the root zone) from which to obtain DNSSEC validation information. Without DLV, in the absence of a fully signed path from root to a zone, users wishing to enable DNSSEC-aware resolvers would have to configure and maintain multiple trusted keys into their configuration.
Maintaining multiple trusted keys by hand is an unmanageable task. ISC DLV removes this need by serving as a trusted repository of entry points through which those keys can be securely retrieved by the resolver when it needs them.
This is true, but by using a DLV repository, the operators of recursive resolvers directly tell the DLV operators what all of the zones they visit are, AND roughly how often they visit them (as the DNSKEY records TTLs time out). Moreover, ISC's DLV repository only has about 350 keys in it (total... for the whole Internet).
ReplyDeleteManaging a trusted key file isn't impossible if you use a service like: SecSpider. Unfortunately, BIND is implemented in a such a way that you can't mix and match with trusted-key files and DLVs, or even use more than one DLV. :(
Eric
DLV does not "spider" the internet looking for keys. It's not a popularity contest here; it's security. If you wish to use a service that adds untrusted keys into your trusted key statement, by all means, do so. If you want security and reliability, use TARs or DLV or both.
ReplyDeleteThere is no conflict; you can use trusted keys -and- DLV at the same time.
Hey Michael,
ReplyDeleteI'm not sure why you quoted "spider?" Further, I don't think anyone is interested in a popularity contest. Of course, you brought that up, so maybe someone is interested? ;)
I think your definition of "trusted" needs some work. What does that mean? Does that mean that you once polled for a "cookie" record from a single location and after that decided any key you saw there (or any key rolled from that key) was "trusted?" SecSpider repeatedly polls from all over the globe at random times and only reports keys that are the same everywhere. It verifies the continuity of DNSKEYs globally and it has more data than (I believe) any other repository (over 10,000). What would an adversary have to do to spoof that (all name servers from all points globally constantly until SecSpider polls)? By contrast, I think the DLV in question creates its notion of "trust" by only making an initial poll from a single place and all users' "trust" hinges on that single first poll of a "cookie" record, right? Can an adversary spoof the cookie and then the DNSKEY?
Also, at least as of last time I heard (v 9.6...), BIND only let you specify a single DLV repo, and that DLV repo overrode any local trusted-key statements. This is something I think I even saw a bug report on. Has that changed? Your statement that you can use DLVs _and_ TARs is interesting too. What TARs are you talking about? Does this mean BIND now lets users add multiple points of reference (say more than one DLV)?
Finally, let me repeat my previous point: if someone uses a DLV, they expose to the operators of that DLV all of the zones they are visiting and at roughly what frequency. As DLV records that _may_ be cached timeout, resolvers must request them again from the DLV. That's a bit of a privacy issue, no?
Before accepting a DNSKEY, we start at the root and walk up using TCP. Each server must respond to the same query, and if it does not respond correctly we will not accept the DNSKEY. The cookie is only used to verify that the person can modify and then sign the zone, and is only checked in this initial check.
ReplyDeleteOnce accepted, we probe for the DNSKEY to ensure that it remains intact and will remove it should it no longer be present.
BIND only allows one DLV registry, but you can have both a trusted-key and a DLV registry defined. In that configuration, DLV will only be used when the normal means of validation have failed -- that is, when a query would otherwise be performed into an insecure area.
As for privacy, sure. This is not a new issue. ISC runs a root server, where privacy is always an issue as well. When you use any DLV system you are allowing a 3rd party to see your queries. ISC is not doing anything with, or even collecting, such statistics.
It's all a matter of trust here. I would trust DLV more than something that literally goes out and looks for DNSKEY records. Part of this is because I wrote the UI front-end, part of this is because I trust its checking. Part is that people intentionally add their zones to DLV through the UI, or indirectly through a TAR that we have verified and imported.
Just because there is a DNSKEY record should not imply, no matter how often it is queries for and no matter where it is queried from, that the key should be trusted. Doing so implies that any key found is ready for use. Perhaps it's in testing. Who knows until those who control that zone release it as ready.
As for a popularity contest, that was simply a response to the count of records. I would take a few hundred zones in ISC's DLV over 10,000 collected DNSKEY records. It's not a matter of numbers, it's a matter of trust.
In the end, people should do what they feel they can trust.
* Before accepting a DNSKEY, we
ReplyDelete* start at the root and walk up
* using TCP. Each server must
* respond to the same query, and if
* it does not respond correctly we * will not accept the DNSKEY. The
* cookie is only used to verify
* that the person can modify and
* then sign the zone, and is only
* checked in this initial check.
Come on... If TCP was sufficient to avoid an adversary, would we need DNSSEC at all, or just DNS over TCP? ;) Seriously though, is it possible for an adversary to spoof a TCP connection? :-P
* Once accepted, we probe for the
* DNSKEY to ensure that it remains
* intact and will remove it should
* it no longer be present.
I'm glad we can both agree that periodic polling to insure integrity makes sense. It shows that polling plays a good roll. However, I'd argue that polling should be done w/ a little more attention to security (like simultaneously from many diverse locations, but at random times).
* BIND only allows one DLV
* registry, but you can have both a
* trusted-key and a DLV registry
* defined. In that configuration,
* DLV will only be used when the
* normal means of validation have
* failed -- that is, when a query
* would otherwise be performed into
* an insecure area.
*
* As for privacy, sure. This is not
* a new issue. ISC runs a root
* server, where privacy is always
* an issue as well. When you use
* any DLV system you are allowing a
* 3rd party to see your queries.
* ISC is not doing anything with,
* or even collecting, such
* statistics.
Even root servers don't see as much about my traffic as a DLV would. Once I've cached a TLD, I send my traffic THERE until it expires.
You only see some of my traffic at the root, but the DLV will see pretty much all of it. As for the trustworthiness of ISC, I don't think anyone suspects foul play, but I also don't think following a solution that mandates that I expose my privacy is the best route. You can't ignore design deficiencies like the privacy concern.
* It's all a matter of trust here.
* I would trust DLV more than
* something that literally goes out
* and looks for DNSKEY records.
* Part of this is because I wrote
* the UI front-end, part of this is
* because I trust its checking.
* Part is that people intentionally
* add their zones to DLV through
* the UI, or indirectly through a
* TAR that we have verified and
* imported.
So, again, I see you talking about ``trust'' as if its some kind of boolean value. That really seems myopic to me. Really, you don't
_know_ something is trustworthy because the operator of a DLV thinks its genuine. Trust is about evidence. This is how things in
meatspace work too. If you don't absolutely trust a DNSKEY, but there is SOME degree of evidence about it, should you just not visit a zone? What if you want to visit your kid's school web site, but they haven't gotten it into some DLV somewhere, and the parent zone has not signed yet? Should you just say, ``Sorry son, I can't check to see if your school is open today, they didn't register with ISC's DLV...'' No, there are ways to check if this key seems genuine. This is not about ``trust'' it's about authenticity.
* Just because there is a DNSKEY
* record should not imply, no
* matter how often it is queries
* for and no matter where it is
* queried from, that the key should
* be trusted. Doing so implies that
* any key found is ready for use.
* Perhaps it's in testing. Who
* knows until those who control
* that zone release it as ready.
I really think talking about DNSKEYs in some strange absolute terms of trustworthiness is going to retard people's acceptance of DNSSEC. You can't bestow any magical trust of a zone's DNSKEY from ISC's DLV or any other. People want to know that they data they are using is authentic, period.
* As for a popularity contest, that
* was simply a response to the
* count of records. I would take a
* few hundred zones in ISC's DLV
* over 10,000 collected DNSKEY
* records. It's not a matter of
* numbers, it's a matter of trust.
The difference is if someone rolls out DNSSEC, and doesn't get into your DLV, they will be seen to have a key but the DLV will cause resolvers to NOT accept that zone. The 10,000 is to tell people we cover the Internet. Using some magical set of 400-500 vetted keys does not cover a meaningful set of the DNSSEC deployment today, and if that means some zones can't be queried because ISC's DLV does not have their keys, then you are hurting those early movers. Rather, it's too bad BIND doesn't have a policy/priority mechanism to prefer certain data sources, but fall back to others. Again, trust is _not_ absolute... It is filled with shades of gray, and any attempt to polarize it has dire consequences. It should be that users can prefer one data source, but include data from another data source lacking anything else.
* In the end, people should do what
* they feel they can trust.
Clearly which is why options in this space are important so that there isn't just one show in town that mandates who everyone will and
won't trust. ;)