Subject: Re: [homenet] Tunnels to home

From: Curtis Villamizar <[email-masked]>
Date: Sun, 02 Sep 2012 16:08:17 -0400

In message <CAN2Hq07cserc=PHSLNpOf+K9sETLWmQQLPGm04796HY=[email-masked]>
Richard Mortier writes:
 
> (apologies for the delay replying, have been catching up after a trip away.)
>  
> On 15 August 2012 19:30, Curtis Villamizar <[email-masked]> wrote:
> >
> > In message <[email-masked]>
> > Richard Mortier writes:
> >
> >> On 13 August 2012 20:04, Michael Richardson <[email-masked]> 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
> [email-masked]

Curtis

---

From: Richard Mortier <[email-masked]>
Date: Thu, 6 Sep 2012 22:45:59 +0100

...
> *and* are DNSSEC signed is an example of a "signed untrustworthy

ah- thanks. i didn't fully understand the example i think.

...
> 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-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 07 Sep 2012 22:02:24 -0400

In message <[email-masked]>
 
> 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.

Curtis