Subject: Re: [dnsext] Increasing hash collision resilience

From: Florian Weimer <[email-masked]>
Date: Fri, 05 Jun 2009 12:14:08 +0200

* Alex Bligh:

> --On 18 May 2009 07:05:02 -0700 Paul Hoffman <[email-masked]> wrote:
>
>> I do *not* support the use of randomized hashing for DNSSEC; the use of
>> already-defined better hash algorithms (SHA-256) is a much better option.
>
> Assuming that Florian's suggestion was not to mandate use of a nonce
> now,

Certainly not.  The idea was to make sure that it is interoperable
(both in a technical and a social sense), but leave it up to zone
signers whether they want to include it or not.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

--
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: Florian Weimer <[email-masked]>
Date: Fri, 05 Jun 2009 12:18:12 +0200

* Olafur Gudmundsson:

> Once a target DS signature is generated the attacker has only the
> "effective" life signature to play with, trying to
> create a collision signature. If parent is using predictable timing
> values the attacker still has to submit the "attack DS set" during a
> one second window to have a good chance to get the right signature values.

This was true for the certificate validity period in Lenstra's attack.

> The attack you are describing is available against all RR types (DS
> is just most attractive one). Thus if a fix is needed that should
> protect all types not just one.

In many cases, the attack can be avoided by introducing delegation.

> A better solution is to recommend that when signing records the
> timer values be randomly picked from a range for example:
>         sig init                [curr time-256..curr_time]
>         sig expire      [lifetime-3600..curr_time+3600]
>         TTL             [standard_TTL-1024..standard_TTL+1024]
>
> This has no protocol implications.

This should work, too.  Hopefully, it give interested parties enough
bits.  Thanks for the suggestion.