Ran,
Thanks for providing clarification to the list on this topic. I
hadn't noticed the wikipedia entry before. The language regarding
whether DNSSEC is legal to deploy in some countries is unnecessarily
inflammatory. I am not aware of any country prohibiting its
deployment, though I am told that deployment with NSEC is not ok.
Deployment with NSEC3 seems to meet the various privacy requirements,
and, indeed, a number of European countries are actively deploying
DNSSEC. SE, BG, CZ, PT, CH and LI are up and running. Several others
are in the process of deploying DNSSEC and will be functional either
this year or early next year.
For those who care about the technical details, NSEC3 uses a hashed
space to report intervals of non-existent names. This makes it
difficult to enumerate the names in the space. However, a querier can
still walk the zone, though the "walk" is more like a drunken, random
stagger because each probe has to be at some new random place and not
based on the previous probe. With the results in hand, one can then
try a dictionary attack and, if the names are reasonably guessable,
determine which ones exist. For most purposes, this difficulty and
energy to do this has been considered sufficient protection of the
information to meet the perceived privacy needs. At the end of the
day, the information we're protecting is simply the complete list of
names within a particular zone. Information associated with any of
those names, e.g. whois information, is subject to its own controls.
For anyone who wants even stronger protection of the names in the
zone, the "epsilon" approach does the job. "Epsilon" refers to
creating a minimal span for an NSEC response. This requires using the
private key on the fly to create the response, and thus poses some
possible risk of key exposure and also increases the computational
load. However, if a hardware box is used which has adequate
protection of the key and if adequate computational resources are
available, this will be quite adequate. For anyone who is having
trouble following what I have just said, suppose ALPHA, BETA and GAMMA
are instantiated names within the zone, and someone asks about APPLE.
The standard NSEC response is (NSEC ALPHA, BETA), which means there is
nothing between ALPHA and BETA. The querier is responsible for
computing that APPLE is lexicographically between ALPHA and BETA.
This response discloses that BETA is the next name that exists in the
zone. If the querier then asks about, say, BETA0000, he will get back
the response (NSEC BETA GAMMA), and thus he able to "walk the zone" to
find all the names. If the zone is signed with NSEC3, the responses
look like (NSEC xxxx yyyy), where xxxx and yyyy are hashes. The
querier is responsible for computing hash(APPLE) and then checking
that xxxx < hash(APPLE) < yyyy. This doesn't tell him what names were
used to compute xxxx or yyyy. And in the epsilon approach, the
response to a query about APPLE would be (NSEC APPLE APPLE00000...),
thereby asserting that APPLE doesn't exist but not disclosing the
actual name that is next in the zone.
We are providing a map of currently signed and soon to be signed zones
as part of the web site at http://www.dnssec-deployment.org. A few
others are also keeping track of the signed zones.
Cheers,
Steve
On Jun 10, 2010, at 4:46 PM, RJ Atkinson wrote:
(NB: I've revised the Subject line to reflect that this
has moved off-topic from ILNP and is really purely
about DNS, DNSsec, and alleged privacy issues.)
On 10 Jun 2010, at 15:48 , Patrick Frejborg wrote:
Earlier, Ran Atkinson wrote:
Separately, DNS with DNS Security can be used to retrieve
the revised Locator value(s) from the DNS
Found this on wikipedia
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Zone_enumeration_issue.2C_controversy.2C_and_NSEC3
"In addition, the information from an enumerated zone
can be used as a key for multiple WHOIS queries; this would
reveal registrant data which many registries are under strict
legal obligations to protect under various contracts.
I don't have any reason to believe that the quoted claim
above is true. In fact, I have some evidence (below)
that the claim is not valid/correct.
For example, more than one registrar today simply returns
its own contact information in response to a WHOIS query
for a domain that has a private registration. Multiple
queries (for the same domain or for a variety of different
domains) don't reveal anything at all, except that some huge
number of domains that happen to have been coincidentally
registered by the same registrar.
All of those privately registered domains will return
identical information (e.g. the registrar's name and
the registrar's contact information, but will NOT return
the registrant's name or contact information) from a
WHOIS perspective, so there is no privacy issue.
More generally, there is nothing in DNSsec that requires
a registrar to reveal private registrant data. Keeping
that registrant data private is solely a registrar issue,
one that can be solved entirely within a given registrar,
with no changes to the DNS protocol (and no changes to the
WHOIS protocol either).
It is unclear whether DNSSEC is legal to deploy at all in many
countries, unless such lists can be kept private.
That information can be kept private, with one example
approach described above, so there is no actual issue here.
No protocol changes are needed for this in any event.
DENIC has stated that DNSSEC's zone enumeration issue violates
Germany's Federal Data Protection Act, and other European countries
have similar privacy laws forbidding the public release of certain
kinds of information."
This is why DNSsec also has other mechanisms (e.g. NSEC3)
that don't enable zone enumeration. Those mechanisms
(e.g. NSEC3) are widely available now [1], well before ILNP
is widely available. so there is no current issue here either.
Yours,
Ran
[1] According to this URL, the very commonly used BIND
implementation of DNS and DNSsec has included NSEC3
in shipping releases for over 2 years already:
<http://www.isc.org/software/bind/new-features/9.6>
Other DNS implementations also exist with NSEC3 support.
BIND is simply a convenient example to cite, because
it is especially widely deployed at present.
Yours,
Ran
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
