On Fri, 7 Feb 2014, Viktor Dukhovni wrote:
I think that HMAC-sha224 would be wiser, since otherwise a single
dictionary works for all domains.
So what, telnet'ing to port 25 and issuing HELO and RCP TO: is cheaper
already.
There's a difference between online and off-line attacks.
$ wc -l /usr/share/dict/words
479828 /usr/share/dict/words
$ head -100000 /usr/share/dict/words > /tmp/10k
$ time (for word in `cat /tmp/10k`; do echo -n "$word.nohats.ca" | sha224sum; done
> /dev/null)
real 3m9.064s
And that's using only 1 cpu, and a horrible shell kludge.
I'm sure the spammers have awesome LHS dictionaries gathered over the
years. Your proposal does not actually add any security.
You'd have to also ratelimit DNS queries if you go down the path of the
hash being a security feature.
For an NSEC zone, if the hash does not include the full address,
the attacker can trivially perform a lookup in a pre-computed
domain-indendent dictionary. Thus the usernames are easily recovered
off-line. So if you don't do HMAC, you must hash the full address,
not just the localpart.
For an NSEC3 zone, the attacker gets lightly iterated salted hashes
of the query fqdn, and needs to compute the same for each guess of
a plausible user name.
Why do i need to follow the hashes? I'll just brute force a dictionary
list and sent queries. Whether I sha2-224 that once, or once per domain,
is not that big of a difference. hashing is cheap.
Bottom line, hash the full address, not just the localpart.
what's next? using scrypt? pbkdf2?
The hashing is not a security feature. Hashing the domain brings in
other problems, such as case sensitivity that changes hashes but not
DNS names.
Also, not using the domain name allows for CNAME/DNAME entries, so for
example I can add the same record in my "libreswan.org" zone that is
used as DNAME for libreswan.{net|com|ca|fi|nl}. Adding the domain into
the hash would break this setup.
Seriously, if spammers use the location of SMIME/OPENPGPKEYs to find
email addreses's WE HAVE WON THE CRYPTO WARS!
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
