Subject: Re: Proposal to fix NSEC

From: Jim Reid <[email-masked]>
Date: Fri, 21 May 2004 15:11:37 +0100

>>>>> "Alex" == Alex Bligh <[email-masked]> writes:

This discussion is getting off-topic for this list which is supposed
to be about DNS protocol issues.

    Alex> With respect Paul, I think you are handwaving. The wish to
    Alex> have data published in response to a specific query is not
    Alex> necessarily commensurate with the wish to have it published
    Alex> under any circumstances whatsoever.  Many people write
    Alex> emails, and thus publish their email addresses. This does
    Alex> not necessarily mean they want them compiled into lists of
    Alex> email addresses, associated with other data, and sold as a
    Alex> database.

With all respect, I think this is hand waving too. Anyone with half a
clue will realise that by publishing their email address, they have no
control over what others may do with that data. Even when there are
supposedly the safeguards of data protection and anti-spam legislation.
For instance, by responding to this mail I accept the risk that
someone may harvest my address and send me spam even though I don't
want them to do that. Going back to DNS, I doubt very much if anyone
registering a domain name in a TLD cares or even realises that the
whole TLD zone file might be available. Or not as the case may be.
They just want their domain name visible through the DNS protocol.

    Alex> However, the problem goes beyond that. In this instance, in
    Alex> my opinion, the law is merely a symptom of what people want.

A discussion about "what people want" is well off-topic for this list.

    Alex> That's why we are concerned about protocol
    Alex> changes which remove our ability to do protect zonefiles.

It's still not clear to me what those concerns actually are and why
traversing the zone file is such a worry. Maybe I'm just being more
stupid than usual. As Paul has pointed out, there are plenty of ways
of enumerating a TLD zone today, with or without some flavour of
DNSSEC, irrespective of whether zone transfers are possible. If the
concern is NSEC records makes whois disclosure easier, then fix whois:
that's where the personal data lives after all. That data isn't in the
DNS. If it's about copyright, the copyright holder's rights should
still apply. Just like record companies sell copyrighted material on
(copy-protected) CDs but are able to pursue anyone who illegally
duplicates that material.

In some respects, zone traversal might actually alleviate the concerns
of these TLDs. Suppose you put a delegation into the zone that doesn't
have a genuine whois entry or a registrar or end user. The delegated
zone has no web server or MX records so nothing other than the domain
name itself is ever published. And that's found by walking the NSEC
list. If this name pops up in your query logs, voila! The honey trap
has found someone who's up to no good and you can set your lawyers on
them.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 May 2004 15:07:16 +0000

> Paul,

I'm Paul.  He's Robert.

> --On 22 May 2004 13:53 +0700 Robert Elz <[email-masked]> wrote:
> > ...
> > Don't be totally absurd.    As Jaap already showed (after more research
> > than the topic deserved), the European laws have nothing whatever to do
> > with this ... Incidentally, nor does copyright, which has also
> > been mentioned - in order
> 
> ...
> For me the point, however, isn't wholly about the law. It's about what
> stakeholders want. They do not want ccTLD operators publishing zonefiles.
> And ccTLD operators do not want to publish zonefiles. It appears the same
> might be true of VRSN. Current RFCs permit non-publication. ...

Have any of you here looked at <http://www.isc.org/ops/ds/>, perchance?

The thing that's boggling my mind at the moment is that the stakeholders,
or ccTLD operators, or VRSN, believes that by prohibiting zone transfers
they are preventing enumeration.  It just ain't so, and while I'm still
Paul and he's still Robert and I can't authoritatively speak for him, I
suspect that Robert's use of the word "absurd" has to do with the general
misconception that preventing direct enumeration at the DNS protocol level
is actually buying anything for anybody.

> ... Whether or not all these people are unduly worried is to an extent
> a moot question, ...

No, it's not moot, not yet anyway.  DNSSECbis as documented in the current
set of drafts and as implemented in BIND 9.3.0-beta4 has undergone
significant review and lab testing and appears ready for deployment.  If
the DNS protocol development community is going to back away and redesign
it again, then two questions have to be answered first:

   1. what exactly is it that you think you're going to get by making
      the enumeration of your zones an indirect activity rather than
      a direct one, noting that anyone who wants the enumeration can
      get it by indirect data mining techniques...?

   2. why are we doing this in May, when every other time that we've
      pulled DNSSEC back for yet another redesign that's added one or
      two years to the schedule, we've done it in December...?

> ... though personally I agree with Phillip Hallam-Baker's analysis
> that more information is revealed.

If he said that, he was wrong.  More likely you misunderstood him.  The
same information is revealed, it just happens slightly later and is an
indirect activity.  Take a look at <http://www.isc.org/ops/ds/> before
you try to decide what's "finally and actually" revealed, no matter what.
(Noting that the ISC Domain Survey does not use or depend upon AXFR.)

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 May 2004 16:34:39 +0000

> It is perhaps an interest reflection on the workings of the IETF that the
> requirements of those deploying the protocol (ignoring, for a minute, why
> they have those requirements) appear occasionally to be only a secondary
> consideration in protocol design.

I apologize for the apparent truth of that reflection, but it's inaccurate.

SLD holders outnumber TLD holders by a factor of many millions.  As an SLD
holder I can tell you that I do not fear enumeration as much as I fear
spoofing.  There are a few SLD holders who hold the opposite view, just as
among TLD holders you will find both views.

When the "NO RR" was evaluated by the dnsext working group, these opposing
requirements were taken into account, and anti-enumeration lost out.  I had
no dog in that race so this was only of academic interest to me -- "what 
does BIND have to implement?" and "how can we get DNSSEC done in a decade?"
where my only concerns.

If the WG made the wrong choice and if DNSSEC is unimplementable because TLD
holders fear enumeration and so SLD holders will have secure path to the
root zone, then it appears that there's really no choice except to declare
failure.  Perhaps Ohta or Bernstein would like to take a shot at the problem.

> I would suggest there is perhaps a positive correlation between on the
> one hand to the IETF listening to to the requirements of those who
> want to deploy a protocol on the one hand, and the protocol actually
> getting deployed on the other.

Many voices were heard.  Primary among them were SLD holders, who either
don't care about enumeration, or who fear a two-decade approach to
DNSSEC even more, or who fear spoofing even more.

> In the context of a requirement to preserve existing functionlity, the
> fact that *you* think requirements are misplaced (I don't, but who
> knows, in the final analysis you might well be right) doesn't cut much
> mustard when the requirement comes from the internet community, as
> communicated to those who are going to make the deployment decision.

What *I* think, since you mentioned it, is that TLD holders who fear
enumeration think that restricting AXFR is actually preventing
enumeration, and that if they'd spend a few years in the trenches
against spammers and data miners they would come to the conclusion that
"all useful malevolent forms of enumeration are already possible and are
already being done" and would then conclude that a one-decade DNSSEC is
better than a two-decade DNSSEC, given that all other things are equal.

---

From: Jim Reid <[email-masked]>
Date: Sun, 23 May 2004 13:54:00 +0100

>>>>> "Alex" == Alex Bligh <[email-masked]> writes:

    Alex> I'm not going to put privileged legal advice on list (drop
    Alex> me a note off-list if you like) but suffice to say the old
    Alex> saw about ask two different lawyers, get two different
    Alex> answers is all the more true in two different jurisdictions.

But the EU directive in question applies in both jurisdictions. And
anyway the answer a lawyer gives can depend on the question asked.

    Alex> For me the point, however, isn't wholly about the law. It's
    Alex> about what stakeholders want.

Even when they're misguided? Or if they want the impossible?

Note too that this DNS stakeholder wants his zones secured from
spoofing. And he wants that now. Though perhaps that's also a
misguided demand for the impossible. :-)

    Alex> Current RFCs permit non-publication. 

No they don't, though I suspect this depends on your definition of
"publication". No DNS RFC says anything about access controls. Apart
from saying servers can sometimes return REFUSED -- which may or may
not be for reasons to do with access controls -- the RFCs are silent
on this matter. So the current RFCs neither prohibit or allow
non-publication, for your definition of this term. In purely DNS
terms, entering names into a public zone file constitutes
publication. If something isn't to be published, it shouldn't go in
the DNS.

    Alex> The current DNSsec proposal prohibits this. 

Wrong again. The current drafts just make it more explicit that
attempts to conceal a zone's contents by restricting zone transfers --
ie security through obscurity -- are futile. This should not come as a
surprise to anyone. As has already been pointed out, there are many
techniques that are currently in use to enumerate a zone. It seems
some of us haven't yet got over that. Sigh.

---

From: Jim Reid <[email-masked]>
Date: Sun, 23 May 2004 21:25:48 +0100

>>>>> "Alex" == Alex Bligh <[email-masked]> writes:

    Alex> Just to illustrate the point, can you tell me what the
    Alex> domain is in Nominet's zonefile right now, alphabetically
    Alex> immediately following alex.org.uk. The 10 next ones? No, you
    Alex> can't, without access to a secondary.

Why do you think this information is of any value? Why is it worth
trying to conceal it, even though it's not that hard to find? More
to the point, why do these stakeholders you keep banging on about?

---

From: Paul Vixie <[email-masked]>
Date: Sun, 23 May 2004 21:28:02 +0000

> > Why do you think this information is of any value?
> 
> I am illustrating that Paul cannot enumerate the zone either accurately or
> completely.

i never said i could.  what i said was that i could get a complete useful
enumeration, containing everything a spammer or marketroid would need in
order to make "the bad use" of whois that ccTLD's supposedly don't want
made.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2004 17:16:19 +0000

> > Although my ideal scenario would be for Nominet and the IETF to reach
> > a consensus, new specs (if necessary) be drafted, and DNSSEC be
> > depolyed both in the root and in .uk all within 2004, this clearly
> > isn't goint to happen...
> 
> If you replace the word deployed with deployable (*) I think that is
> a realistic target. As Jay indicated, we are happy to provide concrete
> assistance in getting there.
> 
> (*) = production software ready to go.

it's now the end of june.  unless the change to dnssec-bis were as simple as
"add an MBZ octet to DS, DNSKEY, RRSIG, and require current implementations
to ignore RRs where this octet has a nonzero value" then we're not going to
see "production software ready to go" again in 2004.  patches are fine, but
maturity has been a challenging issue for dnssec.  in NSD 2.0 and BIND 9.3.0
we have production dnssec-bis software ready to go.  change dnssec-bis more
than the tiny amount described above, and we're into 2005 before we have
enough maturity to again call it production ready, no matter what patches
are developed or how good those patches are.

i don't think the average person on namedroppers@ realizes how much pizza and
late nights and whiteboards and "operability testing" went into stabilizing
dnssec-bis and getting confidence that it would work.  that's how "the
grandparent problem" was found.  that's how "TCR" was first proposed (and how
"the middlebox problem" was found, which drove "TCR").

patch-and-publish is fine when the torchbearing mob is at the castle walls
demanding a workaround for sitefinder.  it's not fine when reworking dnssec.