Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

I addressed that question in a previous reply.   Your home network does not
have the equivalent security to letsencrypt.org's certificate signing
infrastructure (I hope!!).   Installing a trust anchor means that trust
anchor has signing authority for any name—there's no way to install one
that doesn't.   So now you've opened all those hosts to attack.   Plus, you
have to install the trust anchor on a bunch of hosts.   Aside from the bit
about our charter saying the host needn't be modified, that's an IT problem
that would challenge a lot of fairly computer-literate people, and if apps
are trusted to do it, that's a major security vulnerability waiting to be
exploited.   If you mean install a cert for every device that presents a
web browser, well, eep.   Aside from the "trusted app" issue and the
"that's hard for end-users" issue, I guess that isn't quite as scary, but
I'd really like an operational model that doesn't require it.

I mean, honestly, if it were possible to get a CA to just issue
certificates for "www.home.arpa" on request with no validation, I think
that would be a better answer both from a security perspective and a
usability perspective, but it's not a *good* answer, and I don't think it's
possible anyway.

On Tue, Aug 1, 2017 at 5:06 PM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Ted Lemon <mellon@fugue.com> wrote:
>     barbara> The CABF is about "publicly trusted certificates". There is
> no need or
>
> ...
>     > (2) the issue with browser warnings isn't that they are annoying.
> It's that
>     > if we train users to click through them when managing the homenet,
> we are
>     > also training them to click through them at other times. This
> creates an
>     > attack surface in the user that we'd rather not create.
>
> I was trying to understand how CABF was relevant.
>
> I guess the point was how to get a new trust anchor added *globally* that
> would somehow be able to issue certificates that were relevant/bound to
> home.arpa names?
>
> I don't think that this is an immediate concern; if we had some useful
> experiment that we could do we could do it with a sub-CA or with a private
> anchor.
>
> I think that Windows, OSX, and Android have system-wide ways to install new
> trust anchors that browser will generally trust.  libnss on many Linux
> distros provides something similiar.  I assume iOS does too.  As such, it
> should be possible for an application/app on a home desktop to exist that
> would interact with all the devices involved (providing certificates from a
> private trust anchor), and to install the private trust anchor.
> How one spreads that trust anchor to the rest of the family, relatives,
> etc. is an issue.
>
> but, none of this is really relevant to delegation of home.arpa, I think.
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>