Subject: Re: nsec3 with one hash algorithm: SHA-224

From: Alex Bligh <[email-masked]>
Date: Sat, 12 Mar 2005 17:45:43 +0000

--On 12 March 2005 18:10 +0100 Roy Arends <[email-masked]> wrote:

> Rolling hash algorithms (from mandatory to optional) is problematic, as
> was previously shown on this list. Since there is also no real profit in
> supporting more then one algorithm, we can obsolete the algorithm
> field from the RDATA, and settle on a single algorithm for nsec3: SHA-224
> (rfc-3874).
>
> Any comments ?

I suggest using a longer algorithm (SHA-512), and then specifying a
variable number of bits to truncate to, to enable the signer to achieve
their own balance between non-enumerability and minimization on-wire
packet size. For small zones, this could be less than traditional NSEC
if people don't care about enumerability (if we make sure we treat
weak hash algorithms right).

I also think that those wanting to support weak algorithms, AND those who
are concerned to treat QNAME/label hash collisions right (despite their
unlikelihood) AND those who don't give a fig about enumerability and want
to use minimum CPU cycles will EACH want to support an identity hash
algorithm. That means you need the field anyway (conceivably it
could be 0 for identity, or a number of octets to which SHA-512 is
truncated).

My personal view on the necessity for identity algorithm is that it's
only needed if you want to support weak / deliberately over truncated
hash algorithms, but I understand others' points of view.

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: Roy Arends <[email-masked]>
Date: Sat, 12 Mar 2005 19:20:19 +0100 (CET)

> weak hash algorithms right).

A label has a maximum length of 63 characters. With base-32, the maximum
amount of bits we could squeeze in a label is 315. So, truncation is
definitly needed for sha-512.

> algorithm.

Isn't using identity hash effectively similar as using NSEC ?

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Sat, 12 Mar 2005 13:18:29 -0500

I agree with Alex, but if one algorithm is decided on, I would like it to be
SHA256 at least.  SHA1 was scheduled to be phased out from USG use in '09 (I
believe) and replaced with SHA256.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy Arends
> Sent: Saturday, March 12, 2005 12:11 PM
> To: [email-masked]
> Subject: nsec3 with one hash algorithm: SHA-224
>
>
> WG,
>
> Thanks

---

From: Alex Bligh <[email-masked]>
Date: Sat, 12 Mar 2005 19:21:28 +0000

> definitly needed for sha-512.

Yep. All this talk about every character being valid et al. and I forgot
about the caching nameservers that don't stick to the standard and the
consequent necessity for base-32 or equivalent, and thus in practice
we are limited to 300 or so bits. However, I would still recommend picking
a hash algorithm that is too long and truncating, than one that is
shorter, given we (now) know how difficult algorithm rolling is.

> Isn't using identity hash effectively similar as using NSEC ?

No - think opt-in.

Alex

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Thu, 17 Mar 2005 12:34:32 -0500

<chair-hat on>

>weak hash algorithms right).

SHA-512 is much slower than SHA-1, somewhat slower than SHA-1, given
that for each negative answer authorative server frequently needs to perform
3 HASH operations to complete the wild card proof, IMHO it is prudent to
go for fast over slow.

>hash algorithms, but I understand others' points of view.

Reading this thread is making me have a flashback to pre-RFC2065, people
are worrying to much about "crypto" stuff, not if the modified DNS will work!!

There is NO NEED to pick algorithm now, before any NSEC++ is standardized
we need draft documents, implementations, testing, workshops and
if things work,  new specs.
For now we can use either MD5 or SHA-1 for simplicity.
All testing should be done using a type code that is different from
the final one, I suggest 47xx where xx is the number followed by number
of the NSEC++ proposal in question.

         Olafur

---

From: Alex Bligh <[email-masked]>
Date: Thu, 17 Mar 2005 18:11:02 +0000

--On 17 March 2005 12:34 -0500 "Ólafur Guðmundsson /DNSEXT co-chair" 
<[email-masked]> wrote:

> There is NO NEED to pick algorithm now,

Yes. You are right on this. Apologies.

However, I think  *is* necessary at a relatively early stage to determine
a) Whether support of an identity hash is necessary/desirable and
   whether fallback to that is necessary (because if it is - and I
   think it isn't - then we need to ensure it's covered in the spec,
   and if not, we need to ensure it's not covered).
b) Whether support for short wire format weak hashes is desirable.
c) Alternatively, whether there is ANY need to support more than one
   hash algorithm at all.

Once we have decided (a) and (b), we (well I) can stop blathering about
collisions etc., and we can say "the design decision was to do X"
(whatever that is). All the above decisions don't seem to me to be
about algorithm choice, they seem to me to be about protocol design.
For instance, if we decide NOT to support fallback to identity hash
etc., then if (contrary to my own view) collisions are a problem later,
there is a substantial amount of protocol redesign to do (I think).
YMMV.

Alex

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 17 Mar 2005 22:55:52 +0100

> 3 HASH operations to complete the wild card proof, IMHO it is prudent to

Keep in mind that a public-key verify operation is still necessary.

I believe that the time spent on computing _any_ widely used hash
function, including SHA-*, is insignificant compared to the delay for
the public-key verify operation.

My point is that hash function speed should not be a major argument in
deciding which hash function use.

Regards,
Simon