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

From: Samuel Weiler <[email-masked]>
Date: Fri, 26 Oct 2007 12:27:38 -0400 (EDT)

I was digging through old mail archives looking for NSEC3 hash 
algorithm discussion, and I stumbled across this...

On Wed, 26 Oct 2005, Olafur wrote:

> <chair hat on>
> This is correct, each time a major change is made to the NSEC++ proposals
> we will roll the trailing number to allow identification of whole proposals.
> Removing Selective Security (i.e. Opt-in in marketing speak) is
> a qualifying major change. Similarly dropping the iteration field that
> some are uncomfortable with would also require a suffix change.
>
> The plan is that when the privacy enhanced NSEC (NSEC++ or NSECn)
> gets selected then we will select a new and better name
> before the RFC is issued.
> Right now we are (still) in the solution tuning space.

Despite some (arguably) major changes[1], we have failed to change the 
name of this proposal along the way, as previously instructed.

Would the chair still like for us to select a new and better name, now 
that we seem to have something that's (almost?) stable?

-- Sam

[1] For example, removing hash truncations (in -12), adding the 
NSEC3PARAM RR (in -07), and adding a signaling mechanism (in -06).

--
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: Fri, 26 Oct 2007 14:46:43 -0400 (EDT)

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.

There seems to be a lot of question about whether the technical methods
are properly thought out.

I don't think the general public would support this document, if it were
widely known that it would prevent people from finding whois keys and
prevent them from guessing at email addresses.  These are necessary
features of the domain name system. This DNS information is necessarilly
public information.  It is important to preserve public access to public
information.  I don't think the general public would support a result of
enhancing registry profits by this 'security' system.

These issues are important to the operation and unhindered public use of
the Domain Name System.

I would probably file an appeal against this document, though, my read
of the other comments is that it won't get to that stage for a while.

BTW, although I don't pretend to be a cryptographer, I have read a
number of books on cryptography, and am probably better versed on the
subject than the typical amatuer cryptographer.  I think I can come up
with some technical analysis for an appeal, especially given the
excellent clues to problems posted so far.  However, the policy analysis
should come first. 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.

We have already seen "privacy" used as a cover for protection from
oversight and protection from external monitoring in the NSID draft. In
that case, Root and TLD operators inserted a scheme to hide the
identification of unique anycast servers.  This prevents anyone (except
the proponents of Anycast) from obtaining direct data on Anycast root
and TLD server performance. The subject of anycast performance is highly
contentious.  There was also misconduct involved in silencing dispute in
that case.  The profits of these server operators has been enhanced as a
result of Anycast use, and as a result of hindering efforts to obtain
direct data on Anycast.

This draft is just another use of crypto systems to enhance the profits
of registry operators at the expense of the public interest.  I say 
"no".

		--Dean

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