Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63)

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 1 Nov 2007 11:32:39 +0100

On 26Oct 2007, at 8:46 PM, Dean Anderson wrote:

> So you didn't find anything saying that RFC3833 was to be ignored?
>
> In that case, I assert that RFC3833 states the policy of the IETF, and
> that this draft is out of scope.
>
>
> Making DNS records 'private' is not in the public interest.  This is
> just a scheme backed by registry operators to enhance sales, and does
> not enhance privacy.
>
> I note that a registry person responded to my previous message, but
> declined to include any proof that the draft's introductory purposes
> were indeed true.

(...)
>
>  If one spends time on technical tasks that are
> contrary to policy, the effort is wasted.  And that's what I think has
> happened in this case.
>
>
> I think the technical issues can be solved. However, obtaining the
> solution is a waste of time because this effort is contrary to IETF
> policy and contrary to public interest.
>

Dear Dean,

In my interpretation RFC3833 is an informational document posting the  
requirements to which _DNSSECbis_ was developed. I'm not sure if a  
debate on the correctness of my interpretation is going to be  
fruitful ;-). So, what follows is a bit of documented history on why  
and how the working group took up this work. The point I am trying to  
make is that the decision to take up this work was not made without  
appropriate discussion on the policy and the various trade-offs.

When DNSSECbis was being (or about to be) last called several  
registries stepped up and argued that they could not deploy DNSSECbis  
given the ease of zone enumeration. One example of such argument is in http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html 
. It was not the only argument, if you look at the various postings  
during that time you will notice that the discussion was 'involved'  
and covered all sides of the argument.

After the WG was satisfied that the zone enumeration could be solved  
by (backwards compatible) extension of DNSSECbis, and that the zone  
enumeration could be solved independently from DNSSECbis, the document- 
set that we now now as rfc4033-35 was shipped was shipped. (see e.g http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html) 
.

Finally the working group was asked if they wanted to take up the work:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01981.html

After discussion in the face to face meeting (http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02149.html 
) the item was included in a new charter:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00366.html 
.

Kind regards,

--Olaf Kolkman

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

--
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: Dean Anderson <[email-masked]>
Date: Sun, 4 Nov 2007 21:38:37 -0500 (EST)

> appropriate discussion on the policy and the various trade-offs.

If you mean to assert the informational status of RFC3833 as meaning it
doesn't state a policy, I think that argument is unpersuasive.

If you mean to assert that policy violations can't be raised in 
last-call, I think that argument is also unpersuasive.

The IETF has no proper public interest in helping registries improperly
assert 'database copyright' rights to public information by technical
methods.

> given the ease of zone enumeration. One example of such argument is in
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html

They wrote:

======================= begin block quote

However, for those of you that have asked, this is the gist of our legal 
advice...

As compilations, zone file databases are protected under EU law by
?Database Right?. As a derivative work of the main register from which
they are sourced, they are likely also to attract copyright protection
in addition to or in place of database right.

Both database right and copyright are negative rights in that they
prohibit certain acts (primarily, copying the whole or a substantial
part of the materials) but do not grant positive rights (unlike, for
example, a patent, which grants a monopoly on the material involved).
Database right is unique to countries which implement European Community
law, but copyright is more universal.

======================= end block quote

As I said, the IETF has no legitimate interest in helping registries
assert these rights by technical means. Frankly, the zones are public
information, and the registries do not have a right here at all. They
did not "compile" this information. The registries are performing a
service for which they are entitled to charge service fees. However,
they do not own the DNS information collected.  If the registry is 
decertified, it must turn over this information. That can't happen if 
there is a copyright asserted. This is a very serious problem that must 
be stopped at all levels.

If these registries can't use DNSSEC because they might not be able to
assert database copyright claims on public information, too bad for
them. Good for the rest of us.  The policy requirements are clearly 
stated.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 5 Nov 2007 09:25:46 +0100

> doesn't state a policy, I think that argument is unpersuasive.

We seem to have to agree that we disagree.

> last-call, I think that argument is also unpersuasive.

I am not asserting that you cannot raise such issues during last call,  
by all means; last call review on all aspects of technology is useful.

What I tried to bring across is that we had this discussion in the  
working group about 3 years ago. During that discussion we saw folk  
arguing your view and some supporting other views. At that point in  
time the working group re-chartered to work on this. That should have  
been the time to put a firm break on the work. Today, at IETF last  
call, the IETF did do the technical work and implementors did invest  
in implementing the technology[*].

In my opinion the IETF should design technology that folk can  
implement given the boundaries of operational reality. It turned out  
that in the history of DNSSEC we did a pretty bad job by doing so  
because the _proper_ operational folk where not paying attention to  
the design space when work was done. For instance RFC2035 did, with  
hindsight, not understand the problems of parent-child key  
interactions for large registries, that lead to DNSSEC-bit. When  
RFC3833 was written the policy folk ---a specific sub-group of the  
operators species :-)--- did not pay attention. They only payed  
attention during last call for DNSSEC-bis (and here I refer to the  
threads from which I quoted a number of messages previously).

It turns out that DNSSEC is a difficult technology to sell because the  
incentives for deployment is not well aligned with the costs of the  
deployment. In my honest opinion the only way to get deployment is  
when there will be a sufficient number of large TLDs that offer DNSSEC  
on their zones. To me that seems a prerequisite for the client side to  
invest in deployment and that seems to me a prerequisite for further  
development on top of DNSSEC. Without NSEC3 and its OPT-OUT feature  
there are significant TLDs that will not play in the DNSSEC space  
because their costs will be prohibitive. For instance they would have  
to violate their own policy.

The strong point of NSEC3 is that it has been designed in such a way  
that it can be completely ignored. If zone operators choose not to  
implement/use NSEC3 they will be able to deploy DNSSEC as is. If DNS  
client choose not to implement NSEC3 then they will continue to see  
the TLDs that deploy NSEC3 as if they are not signed. In that way the  
technology is not forced upon folk who do not want to deploy the  
technology. If NSEC was being deprecated and NSEC3 were to become  
mandatory, and thereby _enforce_ policy, then I would be much more  
sympathetic to the "the DNS is public" argument. But with NSEC3 that  
policy discussion can proceed out of the IETF and the technology is  
able to deal with the tussle.

Kind regards,

--Olaf (no hats)

[*] For full disclosure, NLnet Labs is one such implementer; Our  
authoritative server NSD is NSEC3 ready. NSEC3 will be a feature for  
the forthcoming recursive nameserver. We only started our work _after_  
NSEC3 was chartered. Funded by charity and all will be available under  
BSD license.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 5 Nov 2007 16:49:40 -0500 (EST)

On Mon, 5 Nov 2007, Olaf M. Kolkman wrote:

> > If you mean to assert the informational status of RFC3833 as meaning
> > it doesn't state a policy, I think that argument is unpersuasive.
> 

Perhaps. But under your interpretation, the document has no meaning
whatsoever. This is contrary to the rules for interpretation of
documents.

> time the working group re-chartered to work on this. 

I reviewed these charters:

Oct  6, 2003 The IESG  WG Action: RECHARTER: DNS Extensions (dnsext)     
Jan 29, 2004 The IESG  WG Action: RECHARTER: DNS Extensions (dnsext)     
Feb  9, 2005 The IESG  WG Action: RECHARTER: DNS Extensions (dnsext)     

I did not find anything that would put NSEC on the agenda, nor anything
that specifically reversed RFC3833, nor anything that would have
asserted that the DNSEXT WG would or should assist with Database
Copyright. Nor is there any obligation to assert Database Copyright, as
the draft introduction claims.  I appear to have been misled.

> That should have been the time to put a firm break on the work. Today,
> at IETF last call, the IETF did do the technical work and implementors
> did invest in implementing the technology[*].
> 
> the design space when work was done. 

I have a diffferent view of that, too. I think perhaps the improper
operational folk _were_ paying attention, and that others who actually
knew about crypto (eg. Dr. Bernstein) was rudely told to pound sand.

		--Dean

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Nov 2007 10:16:09 +1100

> the draft introduction claims.  I appear to have been misled.

	NSEC3 is not about "Database Copyright".  It's about restoring
	properties that were lost with the introduction of DNSSEC.

	i.e. it was virtually impossible to find the names in a zone
	without being in a position to intercept queries from people
	with apriori knowledge.

	If registries believe that will help with their "Database
	Copyright" issues, well that's their belief.  I never
	believed that NSEC signifantly changed the ability to find
	names as keys for whois queries.  For registries there are
	enough other sources of apriori knowledge that their
	arguements were very weak.

	It didn't however prevent the rest of us realising that
	there are parts of the DNS where there isn't a lot of apriori
	knowledge and that people depending apon that property
	should still be able to sign their zones.

	Optin/out on the other hand will help registries as it
	reduces the memory required to serve a signed zone.  However
	whether that is in the interests of public is still, very
	much, debatable.  Being able to spoof away a delegation is
	not desirable and would not wish a infrastructure zone to
	do this.

	When NSEC++ work went ahead it was stated that this should
	be a investigation into "is it technically feasible to do
	this".  The question about optin/out was left to be debated
	at a later stage as was should this become part of DNSSEC.

	I think there is consensus that NSEC3 is technically possible.

	I have seen no discussion about whether optin/out should be
	kept or not.

	I have seen no formal discussion asking the question "should
	NSEC3 be incorporated into the base DNSSEC".  At the moment
	it is still a experimental extention.

	I, would have no problem with NSEC3 being incorporated into
	the base DNSSEC.

	I think there should be a an applicability statement that
	optin/out should be *not* deployed in infrastructure zones
	despite the obvious memory benefits.  Such zones should
	be asserting that there is a delegation even if the contents
	of the delegated zone can be spoofed away.

	I would be happy for optin/out to be removed as it complicates
	the implementation for minimal benefit.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: bert hubert <[email-masked]>
Date: Tue, 6 Nov 2007 00:44:29 +0100

> 	I think there is consensus that NSEC3 is technically possible.

As a slight dissent, I'd like to state NSEC3 would be the most complex
protocol element of any protocol I've ever implemented. Or ever seen, for
that matter.

So practically, I think it is slightly over the edge of what is technically
possible - even though it might very well be sound in theory. Given the
smarts of the people working on speccing it out, this is probable.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: "Blacka, David" <[email-masked]>
Date: Mon, 05 Nov 2007 19:02:16 -0500

> smarts of the people working on speccing it out, this is probable.

Given that at least three implementers that I know of have implemented
it and had the implementations interoperate, I think that it is clear
that is technically possible.

-- 
David Blacka                          <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Dean Anderson <[email-masked]>
Date: Mon, 5 Nov 2007 19:50:54 -0500 (EST)

> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html

In that messages, they wrote:

So the problem and premise is database copyright.

As the draft-12 states in Section 1:

   An enumerated zone can be used, for example, as a source of probable
   e-mail addresses for spam, or as a key for multiple WHOIS queries to
   reveal registrant data which many registries may have legal
   obligations to protect.  Many registries therefore prohibit copying
   of their zone data; however, the use of NSEC RRs renders these
   policies unenforceable.

There are no _obligations_ to protect this data. The data is public.  
This is just about Registries trying to use database copyright to assert
ownership over public information, and their effort to obtain technical
methods to enforce their dubious legal assertions. Their interests are
contrary to the interests of the internet community, and in particular
the ISOC, in preserving public access to public information.  The ISOC
has a duty to the public trust to preserve public access to this
information.

> that is technically possible.

I don't know about 3 implementers, but I agree that I _expect_ it should
be possible to fix the technical problems identified.  However, those
problems are not fixed in this draft (12). Draft -12 still has serious
technical problems.

		--Dean

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Nov 2007 12:58:58 +1100

> > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html

	There were also arguements about the lost properties.  If
	memory serves me Dan made such a arguement.  Guess which
	one persuaded me to not complain about doing NSEC3.

	Olaf cannot know which arguement(s) caused people to make the
	decisions they did unless he went and asked them or they
	volunteered the information.  He can only know what the
	result was.

	I know, I completely, dismissed the whois arguement for
	NSEC3.  The need to do something stood on its own merits
	even after dismissing those arguements.

>    of their zone data; however, the use of NSEC RRs renders these

	So what.  It's one of many rationals for NSEC3.

		  IT IS NOT THE ONLY ONE.

> problems are not fixed in this draft (12). Draft -12 still has serious

	Please point out the technical problems.  Arguements about
	rational or procedual issues arn't productive and will
	cause any technical problems to be missed.

	Mark

---

From: Dean Anderson <[email-masked]>
Date: Mon, 5 Nov 2007 23:34:53 -0500 (EST)

>       one persuaded me to not complain about doing NSEC3.

The "lost properties" weren't lost, because they didn't exist
previously.  You have to have something before you can lose it.  As
RFC3833 states, those properties aren't suitable goals for DNSSEC. The
"lost properties"  arguments are just a weak attempts to couch the
database copyright issue in more obscure, more palatable, technical
terms.  But it is easy to see through those efforts.

> 	cause any technical problems to be missed.

This has already been done by others. The problem, as I understand it,
is that the present draft steers into a corner with SHA-1 hash, and the
hash cannot be replaced securely.  This technical problem is probably
hard (like rekeying), but should be surmountable. But it is not worth
the effort since we know now the effects of this technology contradict
IETF policy and public interest.

But I do think that arguments about policy and procedural issues are
relevant to the last call, as Olaf noted in agreement.

I think this draft cannot pass now for technical reasons and cannot ever
pass for policy reasons.

		--Dean

---

From: bert hubert <[email-masked]>
Date: Tue, 6 Nov 2007 07:57:18 +0100

> that is technically possible.

Yes - but already we find that more needs to be done, hence the current
discussions on NSECPARAM, NSEC++ etc. That an implementation can claim to
support X does not mean X is actually technically possible or likely to be
done well.

Perhaps I'm raising the bar here, but we're holding out for good
implementations. And given the length and complication of NSEC3/++/PARAM,
that might in practice be very hard.

	Bert

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 6 Nov 2007 09:10:08 +0100

> the draft introduction claims.  I appear to have been misled.

In the charter the work item as been phrased as:

       o Identify (a) method(s) to prevent the possibility of trivial
         zone enumeration.

The Working group approached this in two ways, one documented in  
RFC4470/4471, which requires on-line keys and on-the fly calculations  
of signatures, the other being NSEC3, allowing for off-line  
calculation of the data needed for authenticated denial of existence.

--Olaf

-Olaf

--Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 6 Nov 2007 09:16:44 +0100

On 6Nov 2007, at 7:57 AM, bert hubert wrote:

> discussions on NSECPARAM, NSEC++ etc.

Well NSECPARAM  is part of the specification. The only thing that  
needs to be documented better, based on IESG feedback, is the  
algorithm agility. That is not a major tweak in the algorithm but a  
description of an operational practice.

> That an implementation can claim to

That is why we have a staged standards track and allow for time to  
mature.

And also 'rough consensus and running code'; in contrast to other  
protocols developed in DNSEXT, there is running code, by multiple  
implementors. And at least rough consensus in the WG.

--Olaf

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Nov 2007 21:17:53 +1100

> terms.  But it is easy to see through those efforts.

	Where does NSEC3 fail to meet the requrements of RFC3833?

	The fact that it provides *more* doesn't preclude it from
	being accepted into DNSSEC.

	NSEC3 meets the requirements of RFC3822 2.6.  Authenticated
	Denial of Domain Names.  It can prove the existance / non
	existance of a name.  NSEC allows enumeration which is not
	a requirement.  NSEC3 denies enumentation which, again, is
	not a requirement.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 7 Nov 2007 17:03:46 -0500 (EST)

> 	Where does NSEC3 fail to meet the requrements of RFC3833?

RFC 3833 Section 1:

   - While some participants in the meeting were interested in
     protecting against disclosure of DNS data to unauthorized parties,
     the design team made an explicit decision that "DNS data is
     `public'", and ruled all threats of data disclosure explicitly out
     of scope for DNSSEC.

I cited this previously, in some more detail. 

> 	being accepted into DNSSEC.

Actually, I think it does in this case because the "more" part violates
the policy and interests of the internet community and promotes the
technical implementation of a database copyright on public information.

> 	Denial of Domain Names.  

Authenticated NXDOMAIN already meets this requirement.

NSEC/NSEC3 appears to be an end-run around RFC3833 Section 1.

		--Dean

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Nov 2007 09:24:24 +1100

>      `public'", and ruled all threats of data disclosure explicitly out

	This is a "don't allow the data to be encrypted" clause.
	The data is still sent in the plain.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 8 Nov 2007 23:36:05 -0500 (EST)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> 	The data is still sent in the plain.

The RFC3833 text above is plain. There are three elements:

1) Protecting against disclosure of DNS data was discussed.

2) Explicit decision: "DNS data is `public'"

3) Threats of data disclosure explicitly out of scope.

NSEC3 is meant to protect against disclosure of DNS data (a topic
discussed).  The NSEC3 draft was designed with the purpose of altering
the public nature of DNS data in order to enforce an improper database
copyright, contrary to the explicit decision cited. And NSEC3 addresses
a problem (data disclosure) that is explicitly out of scope for DNSSEC.

		--Dean

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 9 Nov 2007 17:24:22 +0100

Hello Dean,

> 3) Threats of data disclosure explicitly out of scope.

I would agree that the above is indeed the gist of RFC3833.

> a problem (data disclosure) that is explicitly out of scope for  

After DNSSEC bis was developed on the basis of the requirement in  
RFC3833, folk found out that deploying DNSSEC would violate policies  
_already_ implemented to enforce registry policies. The technique used  
to enforce those policy was blocking of AXFR queries (e.g. through  
TSIG authentication). Deployment of DNSSEC would allow a NSEC walk and  
thereby full enumeration of the DNS zone. The result: those registries  
would _never_ deploy DNSSEC.

Another way to look at this is that DNSSECbis answers leak more  
information about the zone than is required for answering the query.  
NSEC3 is the mechanism to minimize that information leakage. It would  
probably be possible to define some argument that asserts that NSEC3  
does not violate RFC3833 but that would be a polemic exercise. As I  
tried to argue before, the working group went through a long and  
careful discussion, including a recharter, to determine this item in  
scope enough to extend DNSSECbis. So technically one could say that  
the introduction of the NSEC3 document updates RFC 3883.

But all technicalities aside, with NSEC3 available we may see a few  
big registries deploy DNSSEC and that may get us on the upwards part  
of the deployment curve. And although I (personally) support the  
notion that data in the DNS is public and blocking AXFR for policy  
reasons is silly, I realize and accept that there are folk and  
institutions with a different opinion on this.

Enjoy your weekend,

--Olaf

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 Nov 2007 11:39:38 -0500

On 8-Nov-2007, at 23:36, Dean Anderson wrote:

> discussed).

I don't think so. NSEC3 is intended to prevent enumeration of the  
resource records in a zone by a remote third party. That's not the  
same thing.

For example, even if a zone contained NSEC3 records, it's still  
perfectly possible for DNS data to be disclosed to parties who are not  
the originator of a client query (e.g. through traffic intercept,  
query logs on intermediate caches, etc.)

Joe

---

From: Doug Barton <[email-masked]>
Date: Sat, 10 Nov 2007 16:48:19 -0800 (PST)

> The RFC3833 text above is plain. There are three elements:

You seem to be making the claim that once text is enshrined in an RFC that 
it is holy writ, and can never be changed or improved. As far as I know, 
that's not how the IETF works.

> NSEC3 is meant to protect against disclosure of DNS data

NSEC3 is meant to prevent unauthorized users from gaining access to 
information that it is currently possible to restrict them from obtaining. 
Said more simply, it's designed to prevent DNSSEC from removing an ability 
that zone managers have (and many depend on) currently.

It is in no way designed to prevent anyone from directly querying for a 
given label and receiving an answer for that label (even if the "answer" 
is that it doesn't exist).

> The NSEC3 draft was designed with the purpose of altering the public 
> nature of DNS data in order to enforce an improper database copyright,

Once again, NSEC3 is designed to make sure that DNSSEC does NOT alter the 
nature of DNS data as it exists currently, and as a rather substantial 
percentage of the currently deployed base expects it to continue to exist.

It's pretty clear Dean that you have a very strong opinion about whether 
or not any zone manager should be able to restrict access to any 
information in their zone (up to and including zone transfer), however 
your view is far from being unanimous (or one could potentially even say 
far from being well supported).

FWIW, I will repeat the same statement I've been making for roughly 12 
years now. Prevention of zone enumeration is a hard and fast requirement 
to have DNSSEC deployed at any reasonable definition of "widely." To the 
extent that NSEC3 supports that goal, I'm in support of it.

Doug

-- 

 	If you're never wrong, you're not trying hard enough