>>>>> "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. 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 <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
