ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Hash function agility. Recent experience has shown that hard coding a
specific hash function in an application is a really bad idea. (MD5 in
particular is sufficiently broken at this point that using it in any
new application is essentially a nonstarter, but SHA-1 or even SHA-256
should not be hard coded either.)
Somewhat OT, but maybe you confused "hash" and "cryptographic hash" (?)
No confusion on my part - I think the security considerastions here are just
sufficient to call for a reasonably strong hash. Especially since it is so
simple to start with a strong hash and also provide a means to upgrade should
the need arise.
For the purpose discussed here you have a fixed right hand side, and we
can (arbitrarily) say that this can be restricted to max. 50 characters.
That gives us about 200 octets to "encode" a hash of a complete address,
let's say four labels of length 50. To avoid trouble we can limit these
labels to a variant of B32 char.s (we're not forced to use LDH labels),
so that gives us about 5 * 200 = 1000 bits. MD5 isn't long enough for
1000 bits, it would result in more collisions than necessary.
I do agree that MD5 is a bit short, but we don't need anything like 1000 bits
of hash, birthday paradox notwithstanding. SHA-256 is more than sufficient to
start with for this application and will likely prove sufficient for a long
time.
But I've another objection to this idea: For the example "New Orleans
is down", where are the name servers answering these queries from the
backup MX ? If the name servers are also down it won't work when it's
needed.
That's purely an operational issue that existing DNS facilities are more than
capable of handling. Here's one easy way to do it: Have the secondary MX also
set up a local DNS secondary. Now the entire zone will be transferred and kept
up to date. If the primary goes down the secondary will continue to operate,
albeit with stale data, which is why the secondary almost certainly needs to
return 4yz errors for unknown addresses.
Ned