Subject: Re: Proposal to fix NSEC

From: Alex Bligh <[email-masked]>
Date: Sun, 23 May 2004 19:05:12 +0100

Jim,

--On 23 May 2004 13:54 +0100 Jim Reid <[email-masked]> wrote:

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

As I am sure you know, EU directives (as opposed to regulations and treaty
articles) are implemented by national law, and the implementation can vary.
Further, they are implemented in the context of existing national law,
which varies. But heh, let's not make this alt.lawyers.barrackroom.

>     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?

It isn't impossible. We have supplied an example demonstrating making
zonefiles not enumerable via DNSSEC. Noone yet has suggested NSEC2 is
fatally flawed. The consequent effects on delay of implementation may be
undesirable, but that is a different point. Nor, in my view, is
it misguided.

Note people are not asking that it ccTLDs should make it impossible
to discover the contents of their zones to any extent. They are simply
asking that ccTLDs should not themselves publish them in toto.

> 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.

They permit a refused answer. They do not specify how that can be
generated. Where RFCs permit behavior (refused) and do not constain
when that behavior may or may not be used, it is up to local policy.
And, indeed, that administrative (policy) refusal appears to be
utilized by every DNS server codebase in non-minimal deployment,
many of whom claim RFC compatibility.

>     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 --

All it seems to me they say is that NSEC is mandatory, and zone enumeration
is a consequence of NSEC.

> ie security through obscurity -- are futile.

Your view is that it is futile. That view appears not to be shared by
everyone. I would suggest it is not shared by those who bother to lock down
AFXR either. I am surprised if you wouldn't go so far as to allow that
it was a matter of opinion.

And in the end, the view that matters is the view of those who want to
deploy it (and, in registry cases, their stakeholders). Otherwise you will
have designed a protocol which is perceived as flawed, and no matter how
much you say that the perception is wrong (whether you are right or wrong),
it's deployment will be significantly hindered. I can tell you that the
interest in zonefile enumeration and spam, exceeds interest in DNSSEC
deployment by a couple of orders of magnitude in terms of the people I talk
to. Many see the security issues in DNS fixed by the little padlock that
appears on their web browser. Many of the more enlightened ones see DNSSEC
as an undeployable nightmare. Please bear in mind I am making the foregoing
statements as a DNSSEC supporter, and in the context of an organization for
whom deployment of DNSSEC is a key strategic aim. The point is that if you
want better stakeholder acceptance, and hence greater deployment, listening
to people's concerns is important.

To me it seems a fair view of the argument goes like this:

1. Current DNSSEC permits enumerability. Previous DNS did not prohibit
   disallowing enumerability through AXFR, and as such that became a
   feature in all significant nameserver deployments, that has been
   utilized by many people.

2. Some people view preventing enumerability as important from a
   local policy point of view. Amongst those are ccTLD operators who
   are concerned for reasons of data protection, copyright, spam and
   local internet community driven policy. Also amongst those are
   certain members of the security community who fear leakage of
   information.

3. A further number of people believe the policy of those in (2) to
   be futile, for various non-DNSSEC related reasons.

4. Fixing the concerns in (2), via NSEC2 or otherwise, can only delay
   DNSSEC being ready for deployment. Everyone wants DNSSEC to be
   deployable quickly. It is possible there is a fix or workaround
   less likely to delay than NSEC2, but if there is, it hasn't been
   published here.

5. Fixing (2) is likely increase the speed and scope of deployment
   once the protocol is ready for deployment, on the basis those holding
   view (2) above are less likely to deploy, and less likely to deploy
   quickly, if their concerns are not addressed. Further, fixing (2)
   after significant deployment is likely to be problematic.

I believe (3) is a red-herring for this group: it seems to me a local
policy issue, and however ill-advised you might feel people to be to take
that policy, the case is at least arguable and new revisions of protocols
should not break existing functionality.

What I believe we are talking about is a simple trade-off between (2) and
(5) on the one hand, and (4) on the other.

Alex

--
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: "D. J. Bernstein" <[email-masked]>
Date: 23 May 2004 19:27:50 -0000

Jim Reid writes:
> The current drafts just make it more explicit that

I have two TXT records for names of the form k.cr.yp.to, where k is a
hex MD5 hash of some cryptographic data. One of them is

   '762fa7ce541bf0817b4f913a2b51a5cd.cr.yp.to:0d32ae8d1ef36e9c71fef18c9a603299

in tinydns format. Please tell us the other one.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Ted Hardie <[email-masked]>
Date: Sun, 23 May 2004 12:46:13 -0700

At 7:05 PM +0100 05/23/2004, Alex Bligh wrote:
>to.

First, to mention something that is in no way Alex's fault, I have to say
that I find the use of the term "stakeholder" makes my teeth hurt.
Different individuals have different interests, and lumping them together
such that "regulatory powers with guns", "captive customers", and
"end users" are all in the same bucket just makes no sense to me.
Not all that salient, really, so forgive the digression.

Second, we're here to make engineering decisions.  We're not trying
to make those in ignorance of regulatory realities or operational
desires, but we have to recognize that it only makes sense for
us to discuss them here in terms of the engineering effects (we're
not going to change regulations in any jurisdiction, get people to
be "more interested" in one thing than another, or otherwise change
the political or economic landscape).  We also need to recognize
that the DNS is used in many jurisdictions for many different purposes.
At this very late stage, taking in a last minute change to this set of
specs both doesn't serve the long-unslaked thirst for deployment
and would appear (note that verb, please) to privilege one set of
interests after long discussion had come to other conclusions.

Put bluntly, we're at the "find technical errors stage", not the design
stage.  The behavior folks are trying to adjust is a known element of
the design and has been for a long time.  It is not a technical error
and a last minute attempt to adjust it doesn't make sense.

Speaking personally, and with regards for all concerned,
						Ted Hardie