Subject: Re: hash algorithm roll

From: Alex Bligh <[email-masked]>
Date: Thu, 03 Mar 2005 15:25:27 +0000

--On 03 March 2005 14:43 +0100 "Olaf M. Kolkman" <[email-masked]> wrote:

> I think we all agree that by using a scheme like the algorithm roll we
> can reliably move NSEC to NSEC3. Those validators that do not have NSEC3
> implemented will have a "signed record" that will tell them this zone
> will use NSEC3 and those validators that do not understand NSEC3 will
> treat the data from that zone as insecure.
...
> In other words I think that hash-algorithm rollover has its problems
> unless we make clear to the validator which hash algorithms to expect.

Just out of interest, is hash-algorithm rollover that important in
practice?

Would it be a Very Bad Thing (tm) if hash-algorithm rollover was handled
just like the NSEC->NSEC3 transition you describe - i.e. fix supported
hash algorithms in NSEC3, code in lots of hashes with variable
truncation parameters, deprecate any found to be terminally weak,
and if we end up with no usable hashes, invent NSEC4 with some working
ones and roll to that in the same way as NSEC->NSEC3?

Alex

--
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: Samuel Weiler <[email-masked]>
Date: Thu, 3 Mar 2005 15:05:47 -0500 (EST)

> Just out of interest, is hash-algorithm rollover that important in

Happily, we have a requirements document for this problem
(draft-ietf-dnsext-signed-nonexistence-requirements-01.txt).
It does not include hash function rollover as a requirement.

The more time I spend on this, the more willing I become to answer
"no" -- I'm willing to accept not being able to roll hash functions.
I'm even willing to accept the current document's instructions for
what to do with NSEC3 RRs w/ unknown hashes: discard them.  I don't
think it's good engineering, but if it's sufficient for those who want
NSEC3, it will get us NSEC3 (and hopefully signed zones) sooner while
taking less effort, and that's a good thing.

Perfect is the enemy of deployed.

-- Sam

---

From: Alex Bligh <[email-masked]>
Date: Thu, 03 Mar 2005 20:35:35 +0000

> taking less effort, and that's a good thing.

Actually I think I may have an engineering reason why not supporting
rollover is a good idea - it's (provably) never actually going to be
useful.

Let's assume:
A. NSEC3 (as finally published) supports the following types of hash
   i)   identity 'hash'
   ii)  trivially invertible (e.g. 32 bit XOR) test 'hash' so those
        worried about collisions can test it.
   iii) SHA-1
   iv)  SHA-512 truncated to n octets for various values of n
   v)   WHIRLPOOL (512 bit) truncated to n octets for various values of n
   and that all the above are mandatory

B. There exists some mechanism of doing a hash algorithm rollover
   (yes, some people may consider this counterfactual, but hang in there,
   I think I'm coming out on your side).

C. There is a (subsequent) requirement to do an algorithm rollover.

If so, one has to ask what on earth would have driven the requirement? The
only thing I can think of is that one or more of the useful hashes (iii)
(iv) and (v) is found to be broken in some way, i.e. partially invertible.
The zone publisher no doubt wants to prevent enumeration, or they'd be
using the identity hash, or would be unfussed about the breakage. Now, if
some, but not all of the useful hash algorithms in the standard are broken,
they can 'roll-over' to another (supported) algorithm - this isn't a real
roll-over problem, this is just "take your next version of the zone with
different algorithm NSEC3" - the resolver must either support NSEC3 and all
the algorithms on publication, or none. EG if SHA-1 is broken, the signer
can switch to (say) SHA-512 truncated, because he knows all resolvers must
support that.

So the only requirement for a real rollover (where you face the possibility
that a resolver does not understand an algorithm you've newly introduced)
is where ALL the hash algorithms available in the (as published) NSEC3 are
inadequate and so you've introduced a new algorithm (say a newly designed
SHA-1024). But then, by assumption, you CAN'T do a useful rollover - i.e.
you can't usefully support both old resolvers (which don't understand new
fangled SHA-1024), and new resolvers (that do), because to do so you'd have
to publish NSEC3 records generated with both hash algorithms, and that
would mean that an attacker need only signal that it is an old-resolver
(however that's done), receive the old NSEC3 records, and attack those.

The only type of rollover that's useful in the "help all my hash functions
have become useless and I'm now worried about enumeration" scenario is to
cease publishing NSEC3 records with ANY broken hash function. If you're
going to publish NSEC3 records at all, that means you ONLY publish with
new and (by old resolvers) unsupported hash functions. In this instance, it
seems to me a better type of rollover would be much like that suggested
between NSEC and NSEC3: generate NSEC4 RR's to replace all NSEC RRs
and say "this just isn't going to work with NSEC3-only resolvers".

Let's just make sure on publication there are some ridiculously long
hash functions in there so this "never happens" (watch me eat my
words later).

Alex

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2005 08:05:42 +1100

> Perfect is the enemy of deployed.

	But when does the list of things that can't be done w/
	NSEC3 get so big that we say "this proposal is broken"?
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]