Subject: RE: UPDATE and NSEC3 parameter transitions.

From: "Rose, Scott" <[email-masked]>
Date: Mon, 28 Aug 2006 09:04:38 -0400

Personally?  I don't know if we need it or not.  It was one of the
issues that was close to agreement at the informal NSEC3 meeting during
Montreal IETF. If secondaries needed some way to know the NSEC3
salt/iter parameters from the zone information, a new RR at the apex
might be the solution.  

The idea being that once that RR is present at the apex, the NSEC3 chain
with those params is complete.  By extension, if those params needed to
be updated dynamically, then a change to the param RR could be a
trigger.  Although there is the question of do NSEC3 parameters need to
be updated dynamically.  Is there a good reason?

Scott

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Olaf M. Kolkman
> Sent: Monday, August 28, 2006 8:41 AM
> To: IETF DNSEXT WG
> Cc: Rose, Scott
> Subject: Re: UPDATE and NSEC3 parameter transitions.
> 
> 
> On Aug 28, 2006, at 2:19 PM, Rose, Scott wrote:
> 
> >
> > Someone might want to increase the number of iterations or 
> salt.  Not 
> > just because of a collision, but to add to the cost of dictionary 
> > attacks when new hardware is available to attackers.
> >
> > I don't have a solution to Mark's question (off the top of my head).
> > However, if the WG decides that the NSEC3-parameters RR is needed, 
> > then I could see any changes to that via dynamic update or 
> in a static 
> > zone file might trigger regeneration of the NSEC3 chain.
> >
> 
> Hmmm....
> 
> Are we sure we _need_ this.
> 
> I think that we are in a stage of protocol development where 
> we should decide what is _need_ and what is _nice_.
> 
> IMHO there is no need to being able to change policy 
> dynamically (change salt or iterations can be seen as policy 
> change) it would be nice but I think that it is not an 
> absolute requirement. I would even think that in order to get 
> this thing done we explicitly call dynamically changing 
> policy such as salt and hash parameters a non- requirement.
> 
> 
> --Olaf
> 
> 
> -----------------------------------------------------------
> 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: David Blacka <[email-masked]>
Date: Mon, 28 Aug 2006 09:49:36 -0400

> salt/iter parameters from the zone information, a new RR at the apex

This is NSEC3 Issue 18 <http://www.nsec3.org/cgi-bin/trac.cgi/ticket/38>.

Based on the feedback received so far, the editors are moving forward
with defining the NSEC3-PARAM RR (solution #2) in the forthcoming
version of the draft.

Obviously, any further discussion on Issue 18 (or any of the other
issues) is welcome.

> be updated dynamically.  Is there a good reason?

I think this feature is certainly possible, however, I do not think it
should be a requirement.

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