In message <[email protected]> Michael Thomas writes: > On 09/11/2012 11:07 AM, Evan Hunt wrote: > > > My home zone is cluttered up with the names of a couple of dozen > > laptops and ipods belonging to neighbors and visitors over the past > > year. It's probably my own fault for misconfiguring DHCP (I don't > > think it's doing the right thing in the "on expiry" block, and it > > hasn't been a high priority for me to fix it). But if we're going to > > be supplying DNS data from multiple sources -- DHCP, mDNS, maybe > > others -- then it might be a good idea to manage time limits on the > > demand side. > > A more fundamental question is enrollment. Security considerations are > usually the sworn enemy of zeroconf like solutions. How we make those > tradeoffs will most likely be a difficult conversation. What gives > something on my home network the right to announce itself, offer > services, change state in some repository, etc, etc? > > If we're using the property that they need to have access to my home > wifi as proof the device is "mine" rather than "somebody else's", then > lets stop right now with the posture that what we're doing is > "zeroconf" because configuring a wifi password is most certainly not > "zeroconf".
We had a similar discussion before and I pointed out that for security some form of exchange of keys or certificates was needed. Having a factory configured root DNSSEC certificate gets one form of trust anchor. The browser certificates provide another, possibly very flawed forn of trust anchor. A means to create a local certificate and manually distribute this could be the basis of a local trust anchor for local addresses and names. For specific services it may be best to have certificates or keys exchanged between client and server. > Which brings me to: we shouldn't be hung up with "zeroconf", we should > be shooting for "littleconf". Agree. Insecure with zeroconf. Secure with littleconf. And insecure is bad. Very bad with GUA. > Mike Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
