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

[James Cloos <[e-mail]>]

>>>>> "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.

VD> HMAC with the domain as a key makes rainbow tables less useful.

If hmac nonetheless isn't used, then the nsec3 hash SHOULD be.

The issue of normalization (before hashing) remains, as foo will
generate a different hash than LHS or Lhs (or lHs), not to mention
the differences between NFC vs NFD (eg, <U+E4> vs <U+61 U+308>).

I like the idea of a published policy (perhaps using the token _policy)
to specify the details for that zone.  With lc(nfc(lhs)) as the default
policy, if none is specified.

-JimC
--
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6