Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

[Viktor Dukhovni <[e-mail]>]

On Thu, Feb 06, 2014 at 08:17:10PM +0000, Osterweil, Eric wrote:

> > Switching gears, was any consensus reached on the endoing of the
> > query label?  A truncated HMAC seems to offer better usability than
> > base32.  I think that the specification is in good shape, modulo
> > the query label encoding.  
> 
> I actually have a question on this: is there some reason we are
> talking about HMAC instead of just straight-up using a hashing
> function?  iirc, hashing accomplishes the same goal (for us) w/o
> needing any secret material (projecting a variable length name to
> a fixed length label).  I'm fully willing to believe that I might
> just be missing something.  I mean this just as a simple clarification
> question.

HMAC was proposed to *salt* the hash with a domain-specific key
(namely the domain itself).  The key is NOT secret, but it is
distinct for every domain (encoded in punycode for IDNA domains).

The reason for salting the lookup keys is to make dictionary attacks
on the set of email addresses more expensive.  One could even
NSEC3-style require some number of iterations, but this would
arguably be going too far and there is not a good way to signal to
the client what the iteration count should be.

Clearly any kind of one-way function is harder to brute-force invert
than the trivially reversible base32.  And salting makes rainbow-tables
less practical.  Still Bitcoin mining has led to rather fast hash
dictionary attack codes, and perhaps even salted HMAC is fast enough
to make DNS lookup a viable directory harvesting (via DNS lookup)
attack vehicle.

-- 
	Viktor.