Subject: 11.3. NSEC-to-NSEC3 transition Considerations

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Aug 2006 13:09:03 +1000

Initially transition from a NSEC only DNSKEY to a
	NSEC/NSEC3(SHA1) DNSKEY generating NSEC records.  Once there
	are no longer any valid NSEC only DNSKEYs in use.  It is then
	possible to generate the NSEC3 records.  These can be added
	incrementally or all at once.

	A server should check if there is a complete NSEC3 record
	chain (i.e. NSEC3 record with the SOA bit set) and once
	there is issue only NSEC3 proofs.  If there is not a complete
	chain it should continue to generate NSEC proofs.

	Once a server is generating NSEC3 proofs the NSEC records
	can be remove either incrementally or all at once.

	We also the the reverse proceedure to be described.

	11.4   NSEC3-to-NSEC transition Considerations

	This is the reverse of the NSEC-to-NSEC3 transition.

	The NSEC records for the zone are added using the NSEC/NSEC3(SHA1)
	DNSKEY.  Once this is complete the NSEC3 records can be removed
	starting with the NSEC3 records with the SOA bit set.  This will
	indicate to the server to emit NSEC proofs.

	Next a NSEC only DNSKEYs are generated and the zone is transitioned
	to use the NSEC only DNSKEYs using standard key rollover
	techniques.

	Note: at somepoint we are also going to need to write how to
	transition between different NSEC3 hash algorithms.  This will
	entail specifying additional key types unless we specify a
	range of hashes now.

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

--
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: Thu, 17 Aug 2006 14:31:58 -0400

> 	can be remove either incrementally or all at once.

Thanks for the text!

> 	We also the the reverse proceedure to be described.

Um, OK, I guess.

> 	entail specifying additional key types unless we specify a

You don't need to specify new key types for this.  You just start using
the new algorithm and get the same basic behavior: insecure to those
validators that do not understand it, secure behavior from those that do.

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Aug 2006 14:15:55 +1000

> validators that do not understand it, secure behavior from those that do.

	So we now have a unsecure answer where all the components
	of the answer are secure.  Where I can securly verify any
	record that exists except wildcards but can't get secure
	no data responses or secure nxdomain responses.

	Do we set AD or not when returning a negative / wildcard
	answer?

	With optout we, theoretically, have a delegation in the
	optout range.  The answer at a given name is alway secure
	/ unsecure.

	With this behaviour the zone is unsecure without being
	signaled as being unsecure.

	For testing purposes we need a hash algorithm value that
	validators will never understand but signers do.  I'm
	using 245 for this at present.

	Mark
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Blacka <[email-masked]>
Date: Fri, 18 Aug 2006 09:36:36 -0400

> 	no data responses or secure nxdomain responses.

Correct.

> 	Do we set AD or not when returning a negative / wildcard

Not.

> 	signaled as being unsecure.

It isn't signaled as such at the parent-side delegation, no.

Imagine that the validator gets a negative or wildcard response that
uses NSEC3 records with an unknown hash algorithm.  What does it do?
Since you obviously cannot actually validate the response, you have two
choices: return BOGUS or return INSECURE.

Obviously, we could define this case to be BOGUS, but do we have to? The
validator can verify all of the NSEC3 records and thus with confidence
know that the zone owner chose to use this unknown hash algorithm.  That
is, the validator can securely tell that the response can't be validated.

So, if we ignore the differences in when the validator knows this fact,
it is very similar to using an unknown signing algorithm or unknown DS
digest algorithm.  However, because of the difference in timing, the
entire zone isn't treated as secure or insecure, and thus, every time it
gets a negative/wildcard response from the zone will have to go through
the exercise of verifying all of the rrsets only to conclude that the
response is insecure.  Not ideal, but not horrible either.

If this case is defined as BOGUS, then yes, we will have to define new
signing algorithm aliases (or something) every time we add new hash
algorithms.

Which would you prefer?

> 	using 245 for this at present.

Signers and authoritative servers, correct?  Seems like a good idea to me.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Aug 2006 23:57:42 +1000

> signing algorithm aliases (or something) every time we add new hash

	Actually I would prefer to only accept new hash algorithms
	with a corresponding change in dnskey algorithm identifiers.
	To migrate to new hash algorithm you perform a key rollover
	then you perform the hash algorithm change.  This preserves
	all the logic for identifing if a zone is secure or not.

	Either that or remove hash algorithm agility altogether.
 
> Signers and authoritative servers, correct?  Seems like a good idea to me.

	Yes.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Aug 2006 09:37:56 -0700

Olaf M. Kolkman <[email-masked]> wrote:
> On Aug 18, 2006, at 10:31 PM, David Blacka wrote:
> 
> > Why is this logic important to preserve?  That is, if the cost is
> > having
> >  to allocate new algorithm codes every time we introduce new hash
> > algorithms, what is the benefit?
> 
> 
> Would it be likely that if a new hash algorithm is needed for NSEC3
> proofs it is also 'wise' to introduce a new hash for the signature
> algorithm?

Yes.

-Ekr

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Aug 2006 10:01:49 -0700

> [mailto:[email-masked]] On Behalf Of Eric Rescorla
 
> > > having  to allocate new algorithm codes every time we 
> introduce new 
> > > hash algorithms, what is the benefit?
> > 
> > 

I agree with EKR here. The NSEC3 use is a less sensitive security issue than signature. DNSSEC provides useful security controls in certain scenarios even if there is no NXT, NSEC or anything similar. If you can attack the signature successfully you have full control.

If you feel the need to change the NSEC hash it is almost certain you would also want to change the signature hash. The reverse is not necessarily the case however. 

You probably want to have a constraint here that states that implementations SHOULD support (but not mandate) use of the signature hash as the NSEC hash.

Otherwise you might end up with a case where someone implements a DNS server that only accepts SHA-256 in signatures and only uses SHA-1 as an NSEC hash which leads to an unnecessary incompatibility.

In general I would tend towards limiting the variation in the choice of crypto within the same implementation.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Aug 2006 10:36:44 -0700

Ben Laurie <[email-masked]> wrote:
> Eric Rescorla wrote:
> Not necessarily - for example you might introduce a new NSEC3 hash
> algorithm because its cheaper to compute, or shorter. Neither would
> really matter for signatures.

Ben's certainly right about this in a theoretical sense. I'm just
skeptical that that will actually happen in practice :)

-Ekr

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Aug 2006 18:34:06 +0100

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Aug 2006 11:25:42 -0700

> Sent: Friday, August 25, 2006 1:37 PM

> > >>> having  to allocate new algorithm codes every time we introduce 
> > >>> new hash algorithms, what is the benefit?
> > >>
> Ben's certainly right about this in a theoretical sense. I'm 
> just skeptical that that will actually happen in practice :)

I think that you are both right.

However the premise to this objection and the others being raised appears to be that we must write the spec in such a way as to prevent anyone from ever screwing themselves up ever in any possible situation.

It is reasonable to make sure that we have not painted ourselves into a corner but the starting point for any discussion should be the assumption that at any given time 99% of all DNS servers use the same set of crypto suites and that the only variation of interest is the extent to which a transition to a new standard cipher has been completed.

Scenarios that start off from the position 'assume X supports algorithm A and Y only supports B' are not realistic. We have a very small set of realistic choices: RSA, DSA-2 and ECC versions, SHA-1, SHA-256 and the outcome of the competition.

Not coincidentally those algorithms fit into three distinct sets, algorithms that are deployed, algorithms that we should be in the process of transitioning to in the near future, algorithms that we should expect to be laying the groundwork on for a transition at some point.

For me it is clear that the next algorithm transition has to be to SHA-2 and DSA-2048. There is nothing else that has acceptable strength (128 bit equivalent) and acceptable signature size (64 bytes). We might easily pass a dozen different algorithms in this group but only one is going to emerge as the winner. I strongly suspect that the benefits of ECC will not justify the cost of resolving the IPR issues that certain parties alledge until those claims have expired.