On Thu, Jan 09, 2014 at 02:45:50PM -0500, James Cloos wrote:
> >>>>> "BD" == Brian Dickson <[email protected]> writes:
> >>>>> "VD" == Viktor Dukhovni <[email protected]> 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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
