In message <CAN2Hq07cserc=PHSLNpOf+K9sETLWmQQLPGm04796HY=dr0...@mail.gmail.com> Richard Mortier writes: > (apologies for the delay replying, have been catching up after a trip away.) > > On 15 August 2012 19:30, Curtis Villamizar <cur...@occnc.com> wrote: > > > > In message > > <can2hq05sgfaoz36cmubgwkj+3yzmztyg2mxszb_rzytdo+s...@mail.gmail.com> > > Richard Mortier writes: > > > >> On 13 August 2012 20:04, Michael Richardson <mcr+i...@sandelman.ca> wrote: > >> > > >> ... > >> > which would permit you to validate who I am, even though neither of > >> > have connectivity at the time.. I would cache my DNSSEC path, and of > >> > course, we each would already have the root DNSSEC key. (no different > >> > than how PKIX works...) > >> > > >> > I see signposts as being additional local trust anchors that can be > >> > used. > >> > >> yes, i think we would too :) > > > > You did trim out the example, where due to the trust, whitehouse.gov > > and billthecat.whitehouse.gov are all DNSSEC signed domains. I > > suppose that is why the smiley. > > the smiley is because (as anil's reply said), signpost uses dnssec > precisely to get that trust. a smiley of agreement if you will. > > >> specifically: in the "common case" we'd envisage that each person > >> would have at least one publicly visible signpost, probably hosted in > >> the cloud (whether or not operated directly by them, or through some > >> "signpost-as-a-service" provider) unless they have suitable local > >> resources. > > > > ... and the difference between signed untrustworthy source of > > information and an unsigned untrustworthy is ... what? > > not sure what you mean here - could you expand?
If the client does not have a configured trust anchor (for anything, DNSSEC included) and is getting one from a discovered source on the local network, then anything signed with it is inherently untrustworthy. The example (provided earlier on this thread) where whitehouse.gov and billthecat.whitehouse.gov are successfully spoofed *and* are DNSSEC signed is an example of a "signed untrustworthy source". > > This is putting yet another service in the cloud that need not be > > there, though global DNS could be considered "in the cloud" as > > commonly practiced for the home user. > > > > What we are trying to accomplish is getting a local name service that > > is somehow authoritative for the local site, and optionally can be > > made global. > > > > Putting the mapping to the local printer in the cloud would break > > printing if the cloud were not accessible (hopefully temporarily) but > > for some devices, like home alarms, utility metering, the fridge, > > ... the kitchen sink, with low power wireless, the cloud might often > > not be there. > > we view both the local and global (ie., visible to the public, > probably hosted in the cloud in most cases) as part of the same > federated service. the local service (eg., at home) will continue to > work if you are disconnected. the global service provides for access > to the "local" services from outside that physical network. Does the client have a configured trust anchor for the global service? if either signpost or DNSSEC is using a trust anchor that is discovered dynamically, you have a huge security hole. > -- > Richard Mortier > m...@cantab.net Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
