On Mar 20, 2017, at 5:44 PM, Steve Crocker <st...@shinkuro.com> wrote: > If you assume the local environment is going to get complicated and that > signing of the local domain will become important in order to guard against > hijacking by errant devices inside the perimeter, it looks to me there will > have to be a local trust anchor. For devices brought into the environment, > DHCP already assigns the IP address and the DNS servers. It can “easily” be > augmented to hand out the public key of the local hierarchy. Or, I suppose, > since I’ve just posited that the DHCP server will tell the new device which > DNS server to use, the device could then query the DNS server to find out if > it has a signed .homenet domain and what its public key is.
My theory for how to do the trust anchor is ToFU. When you first notice you're on a homenet, query a well-known name in the homenet domain; that name will have a UUID attached to it. That UUID identifies the homenet; if you've seen that homenet before, you look for the KSK that you stashed for it, and use that as a trust anchor. If you don't recognize the UUID, you're on a different homenet, so you fetch a new KSK and set up a new chain of trust. Of course, this assumes a certain sort of threat model which may not be the right one. What I would expect to see happen is actually that very few stub resolvers validate until something egregiously bad happens that validation would have helped with. and then suddenly practically everything will start validating. So I think it's pretty dangerous to have a situation where that will suddenly break service discovery on the homenet.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
