On 2 September 2012 21:08, Curtis Villamizar <[email protected]> wrote: > > In message > <CAN2Hq07cserc=PHSLNpOf+K9sETLWmQQLPGm04796HY=dr0...@mail.gmail.com> > Richard Mortier writes: > ... >> 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".
ah- thanks. i didn't fully understand the example i think. ... >> 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. we expect that your globally addressable signpost domain is within the global dnssec hierarchy (eg., laptop.mort.io, tv.home.mort.io), and so can use "." as the trust anchor in the first instance, in the same way that other dnssec domains do. to use a local signpost, you should have previously connected to your global signpost to acquire the necessary trust anchor(s) over a secure (private, authenticated) channel. does that make sense? i'm not a security person by training, so it is very useful to get some comment/critique from someone with a deeper understanding of dnssec/security concerns... -- Richard Mortier [email protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
