Re: WGLC: draft-ietf-dnsext-nsec3-09

[Peter Koch <[e-mail]>]

Dear Roy,

thanks for your detailed reply.

> > Step 1 declares collision detection optional, but here's a MUST, which 
> appears
> > inconsistent to me. 
> 
> I'll turn MUST into 'has to'. Would that suffice ?

fine with me.

> > >    special case: NSEC3 ownernames cannot be proven to exist, in 
> general.
> > 
> > Isn't that "_can_ be proven _not_ to exist"?
> 
> NSEC3 ownernames cannot be proven to exist. Proof of existence of an NSEC3 
> ownername requires another NSEC3 record, which makes this a recursive 
> problem.

Proof of existence usually is neither necessary nor a goal because it happens
implicitly by having a (signed) RRSet for a name. Seems we have a before-after
problem here: you're saying it can't be proven, "because of the following"?

> This section is not about QTYPE==NSEC3. QTYPE==NSEC3 is _NOT_ the problem.

Sorry, I've payed more attention to the section heading "Responding to NSEC3
Queries" than to the actual text.

> This section deals with QNAME == HASH(example.com).com

... and independent of type, yes.

> So, we adhere to the statement that NSEC3 RRs do not bring the ownername 
> into existence.

Yes, please ;-)

> Multiple NSEC3 chains are allowed. Not sure what you mean by parallel.

Both chains are full loops, independent of each other (hopefully consistent,
though).

> > Is NSEC3 a singleton
> > type?
> 
> Singleton type is a bind-ism. Assuming that you're asking if an NSEC3 name 

Apologies for having used non implemention-neutral terminology. Still the

> can hold other RR types besides NSEC3, the answer is yes. (i.e. NSEC3 is 
> not a singleton type)

Now we see that the term even was ambiguous. I had SOA's properties in mind,
not CNAME's, i.e., whether multiple NSEC3 RRs may exist at (not for) the
same owner (which would probably imply a collision).

> I've changed it to:
> 
>        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.

thanks.

> > The current text also
> > clarifies 4034 (references to 2929 etc), so is this meant to update 
> 4034?
> 
> I don't know what you mean.

The text is no verbatim copy of what appeared in RFC 4034, but it is more
clear. Should one assume that this clarification now also applies to the
NSEC spec in 4034?

> > > 4.  The NSEC3-Parameters Resource Record
> > 
> > >    If an NSEC3PARAM RR is present at the apex of a zone with a Flags
> > >    Field value of zero, then there MUST be an NSEC3 using the same
> > >    parameters present at every hashed ownername in the zone.  That is,
> > >    the zone MUST contain a complete set of NSEC3 RRs with the same,
> > >    indicated parameters.
> > 
> > It took me some time to read "every hashed ownername" in a way that
> > does not preclude Opt-Out. I think it's important to emphasize that
> > NSEC3PARAM may only be present if there's a full loop of NSEC3 RRs.
> 
> We state 'complete set of NSEC3 RRs with..."

Yes, but "the same parameters" seemed to preclude flags!=0.

> > I'd add that NSEC3PARAM is not a singleton type.
> 
> No. I can't introduce bindisms.

bindism is a bindism.

> The RDATA is somewhat different, so if I'd refer to 3.3, I'd have to state 
> the differences and exceptions. This seems less clumsy.

OK

> > > 5.  Calculation of the Hash
> > > 
> > >    The hash calculation uses three of the NSEC3 RDATA fields: Hash
> > >    Algorithm, Salt, and Iterations.
> > 
> > s/NSEC3/NSEC3 and NSEC3PARAM/
> 
> No. Why ?

Well, isn't the info in NSEC3PARAM used by the server to locate the NSEC3?

-Peter

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