Re: [Last-Call] [DNSOP] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Dec 4, 2020 at 12:39 PM Benjamin Kaduk <kaduk@xxxxxxx> wrote:
Hi Ondřej,

In a similar vein, you said something about the 32-bit timestamp being wide
enough to prevent brute-force attacks.  Could you say a bit more about what
attacks those are that are being prevented?  I'm not really seeing how the
width of the timestamp comes into play for that concern, just from a quick
skim of the document.  (Timestamps tend to not provide much protection
against brute force by themselves, since time is relatively guessable,
especially to seconds precision.)

I think the timestamp being used as input to the hash provides a particular protection to brute forcing.
Since the output (hash) is a function of the input, this means that any attempt to brute force some other element which is an input to the hash, will be constrained by an element over which the attacker has no control.

The timestamp is a monotonically increasing (modulo 32) value, which changes every second.
This places a time window for a brute force attack, to be of a 1 second duration.
Alternatively, it can be considered as increasing the entropy, meaning the brute force attempt would need to include all potential values of the timestamp over the cookie lifetime.
I believe the 30 minutes or 1 hour lifetime adds enough entropy to significantly increase the work required for a brute force attack.

I don't think the absolute size of the timestamp value (in bits) plays any part here.

Brian Dickson
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux