Subject: RE: 11.3. NSEC-to-NSEC3 transition Considerations

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

> [mailto:[email-masked]] On Behalf Of Eric Rescorla
 
> 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.

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.

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Aug 2006 11:25:42 -0700

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

> Ben Laurie <[email-masked]> wrote:
> > Eric Rescorla wrote:
> > >>> having  to allocate new algorithm codes every time we introduce 
> > >>> new hash algorithms, what is the benefit?
> > >>
> > 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 :)

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.