DNS Mischief

[Michael Stone]

On Sun, Jul 5, 2009 at 8:36 PM, Michael Stone<michael at laptop.org> wrote:
>> d) rewrite as an NSS module?
>> e) rewrite in an external DNS resolver?
> 
> Either of these would make it much easier to play with your patch,
> eliminating the whole "now recompile your C library from scratch"
> step. ;-)  

Pff. It got us this far. :)

> (d) would be the cleanest, and the code involved ought to
> be quite short.  With (e) you could make the names available to other
> machines our your local network, which could be cute (or awful, as you
> like).

The real advantage of (e) is that you can make it work on many platforms. The
problem with (e) is that it seems to take more than 80 lines of code.

> Network-disconnection issues also bear thinking about -- if you use a
> local IPv6 address for a local resource, can you handle its migration
> to the "real" network later as it roams off the mesh?  (It might be
> easiest to handle this as a clean disconnect/reconnect rather than
> going down the "mobile IP" path.)

I've thought a bit about this and, for the time-being, my cost/benefit analysis
(and recent professional experience) argues in favor of making apps better at
tolerating address changes in preference to going down the mobility road.

> Thanks for running with this idea, Michael!

My pleasure; thanks for taking the time to reply to me.

> (Although wearing my security hat I'd have to caution that MD5 has been
> deprecated for 13 years now, and even SHA1 is "not recommended for new use".
> Use http://www.ouah.org/ogay/sha2/ -- it's just two files to add, tomcrypt
> not required.)

I agree that MD5 and SHA1 are deprecated as /cryptographic/ hash functions,
but I don't think that we care. Here's why:

Cryptographic hash functions are characterized by three notable properties: 

    1. preimage resistance

        for a fixed result R, how hard is to it to find a message M such that
        H(M) == R?

    2. second-preimage resistance 

        for a fixed message M, how hard is it to find M' != M such that 
        H(M) == H(M')?

    3. collision resistance

        how hard is it to find two distinct messages M, M' such that H(M) ==
        H(M')?

My claim is that we only care about second-preimage resistance against a random
attacker (as opposed to an optimal malicious attacker). 

I believe that this is true because I think that second-preimage attacks by
random attackers accurately model the risk that a user types in a domain name
which, /by chance, rather than by malice/, happens to hash to an address that
collides with an address already being provided by a different service on the
network, or, equivalently, the risk that a user randomly chooses a name the
hash of which collides with the hash of an already present name. 

(In my present view, plain DNS was never meant to handle the threats posed by
malicious adversaries and it should not be relied upon to do so. Those risks
are, in my view, more adequately controlled by other tools like petnames,
reputation systems, PGP, SSH, and TLS.)

Am I just plain wrong?

> (Ob code review: I think you just want to fabricate a new link-local
> address entry based on the hash, rather than cloning and altering the
> existing LL address.  Link-local addresses have the prefix fe80::/64,
> with the lower 64 bits constructed from the first 64 bits of
> SHA256(hostname).  

I chose to clone existing addresses because I thought it was a convenient way
to get the addresses' zone ids (called "sin6_scope_id" in the sockaddr_in6 struct)
right. Have you got a better way to do this part?

> You also should probably make sure that the hostname you're hashing is the
> full canonical host name, ie "cscott.skiffserv.dyndns.org." (note trailing
> dot) not "cscott" or "cscott.skiffserv" or some other abbreviation.  

Hmm. I can see why you might want that from a network principles standpoint,
but I'm not sure that I'm convinced by your argument.

I guess: "patches welcome". :)

------------------------------------------

The design issue that I find myself most interested in after having gotten this
far is: 

My current design is not in any way integrated into the recursive name
resolution process. This means that people who want to bind multiple names must
do so by adding an address to all their interfaces/zones for each name they
want to bind.

On the other hand, if I made something that were integrated into the name
resolution process, they could just run a nameserver for their domain and then
everything else should "just work". (I think.)

Thoughts?



Kind regards,

Michael