In message <can2hq07o16otukocmdxicfwhhmxd9+bfvd_mg8ao1yaadx-...@mail.gmail.com> Richard Mortier writes: > On 2 September 2012 21:08, Curtis Villamizar <cur...@occnc.com> 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...
Yes as long as the "acquire the necessary trust anchor(s) over a secure (private, authenticated) channel" step makes use of a *configured* key or certificate that insures the other side is not spoofed. It can be somewhat like the configured certificates that come with your browser implementation. If so, then in this regard the signpost scheme adds nothing to using DNS with DNSSEC. It is also very much unlike mDNS or any scheme in which a local authority is discovered which may or may not be trustworthy. Another point I had made earlier is that absent NAT (as IPv6 should be), signpost adds little or nothing of value to DNS with DNSSEC. At least it adds little or nothing of value besides NAT support that I could find in (an admittedly brief read of) the URLs cited and add nothing that anyone has been able to articulate on this list other than NAT support that IPv6 should never need. > -- > Richard Mortier > m...@cantab.net Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
