A nit on this topic (with no hats). I never liked the sha224 thing being used for this. If some form of hash is needed I'd much prefer if sha256 was used and then truncated. Morally, sha224 is also a truncated sha256, but it is not bitwise the same. So sha224 is generally treated as an entirely separate algorithm by APIs.
Since sha256 is our current fav. hash function, there's code for that everywhere. And since sha224 is never or almost never used we normally don't need that, so sha224 might not be available on all platforms. (And could be deprecated in future even if it's present now - getting rid of unused code being a good thing.) But the real win here with a truncated sha256 is for people who have to have their code audited e.g. for CC purposes - having to have the sha224 code present for anything could cause them to incur pointless costs when doing such audits - e.g. if the auditor says: "Hey, please prove to me that you don't do any security sensitive things with sha224." This is the same logic that causes us to not want to use md5 even for non-security functions. So, if hashing anything here, please stick with sha256 and truncate the output if you need it shorter. Thanks, S. PS: Yes, I know John's draft doesn't do hashing, but since we're on the topic again, I thought I'd stick in my oar:-) On 01/04/15 02:17, John Levine wrote: >> An alternative is to go back to the original base32 encoding, which >> is lossless, and thus can allow the remote DNS server (a special-purpose >> DNS lookup engine serving a zone with per-user information) to >> decode the local-part and perform whatever fuzzy matching may be >> appropriate. >> >> The lossless encoding can support longer names by breaking them up >> into multiple labels. >> >> This allows static DNS to be published where desired, and custom >> code to produce dynamic results when appropriate. > > I wrote up a draft summarizing the ways one might do mailbox > name lookups in the DNS with something close to the local-part > rules that MTAs have: > > http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/ > > There's two reversible encodings, including a worked out version of > base32 that handles full 64 character local-parts, preserves the > lexical order of local-parts, and makes signed dynamic zones at least > somewhat possible, an implementation of regular expression matching > that I think is cool, but probably doesn't scale adequately for large > mail systems, and a straightforward way to securely identify a web > lookup service. > > As far as I can tell, the base32 approach handles everything that > hashing does, is no harder to use if you want to publish a static set > of names, but still offers the possibility for large mail systems to > serve stuff on the fly. Take a look. I can send you a tiny python > script that turns local-parts into the base32 names if you want. > > R's, > John > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
