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

[Viktor Dukhovni <[e-mail]>]

On Thu, Jan 09, 2014 at 02:45:50PM -0500, James Cloos wrote:
> >>>>> "BD" == Brian Dickson <[e-mail]> writes:
> >>>>> "VD" == Viktor Dukhovni <[e-mail]> writes:
> 
> BD>> So instead of "encoding" per se, what about using a hash function?
> BD>> ... re-use of the NSEC3 code might be reasonable
> 
> VD> An intriguing suggestion.
> 
> Very!
> 
> VD> If the hash is HMAC-SHA1(domain, username), its hex representation
> VD> is 40 octets which fits comfortably into a DNS label.
> 
> As hex; and 40 hex vs 32 base32 isn't enough of a difference to warrant
> adding extra code for base32.  A win overall.
> 
> Should anyone insist of hmac-sha256, though, base32 would be necessary.
> But I've yet to see any credible claims that sha1's vulnerabilities
> affect hmac-sha1, so there shouldn't be a reason for sha2 or sha3.

Indeed, but if one really wants to avoid HMAC-SHA1 because it is
now unfashionable, one can use SHA2-224 to get a 56-byte label.

Choices of canonicalization rules for the HMAC input are identical
to those for the base32 input.  Neither is particularly more amenable
to case-insensitive or other imprecise matching on the encoded output.

So it seems that there is little advantage to base32, and clear
disadvantages.  The only upside I can see for base32 is that with
HMAC the DNS administrator who forgets which user a given key is
for, can't easily recover that information, but he can with base32.
Keeping the user names "secret" is arguably a security feature when
DNS is outsourced.

A sensible administrator will keep the unhashed input names in a
configuration system that generates the corresponding DNS entries.

-- 
	Viktor.