This is a discussion on Re: NSEC3 Issue 27: creating a flag octet. - DNS ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, As I said during the NSEC3 workshop, the stated need for iterations is o To be able to differentiate the hashing (like the salt), to avoid collisions. o To make offline dictionary attacks ...
-----BEGIN PGP SIGNED MESSAGE-----
As I said during the NSEC3 workshop, the stated need for iterations is
o To be able to differentiate the hashing (like the salt), to avoid
o To make offline dictionary attacks much more expensive. It is
relatively easy to obtain a relatively large part of the NSEC3 chain (by
random probing for NXDOMAIN responses). The iterations field count will
prohibit quick dictionary attacks, it says in the draft.
The iterations field, as it would be used to defend against dictionary
attacks, thus has to increase as computing power increases. If computing
power doubles, iterations has to double to provide the same protection.
A 16 bit field can only double 16 times. Depending on how long you think
it takes for computing power to be 16x as powerful, at that time the
iterations field will be 'too small' to provide the same level of
defense against dictionary attacks. To allow for further growth, a
longer bitfield may be prudent.
A reply at the workshop was that a new hash algorithm, the '1024x SHA-1'
(or something along those lines) algorithm can be defined in that event,
that would provide an extension for the iterations field.
An alternative could be to use the iterations field as 15bit, and use
the high 16th bit to denote a 256x increase in value. This results in
the same range of values for iterations as before (albeit with less
Note I am only discussing the 16-bit iterations. Flags field is fine.
I also have not met people that voiced a high iterations count was
important to their interests.
Mark Andrews wrote:
>> During the last NSEC3 workshop in September, the following suggestion
>> was made:
>> Create a single octet in the wire format of both the NSEC3 and
>> NSEC3PARAM records dedicated to flags. Only one flag would be defined
>> initially, the Opt-Out flag.
>> The purpose for this change would be twofold: 1) to allow a future
>> specification to define new flags for, e.g., dynamic update features. 2)
>> to make the wire format a bit friendlier to parse.
>> The main proposal for how to actually create this octet is to convert
>> the high order octet of the iterations field (which is where the Opt-Out
>> flag currently resides anyway) and dedicate it to flags, thus shortening
>> the iterations field. The new maximum iterations value would be 65535.
>> The Opt-Out flag would be defined to be the low-order bit in this field
>> (which would preserve the presentation format).
>> Obviously, there are possible variations to this proposal. For
>> instance, we could keep the iterations field 3 octets long, add a flags
>> octet, and move the Opt-Out flag to it. This would actually increase
>> the maximum number of expressible iterations to 16777215 (from 8388607).
>> Comments? Suggestions?
> As I pushed for this I'm in favour of it.
> 2 octet iterations.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.