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

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 01 Aug 2017 11:52:49 +0200

>> you couldn't use the fact that you can publish in a name in it
>> to do the ACME authentication.
>
> there SHOULD NOT be the ACME authentication or any neccessarity of any
> other authentication, as these domain names need not be unique ...
>
> in case you use 'teddynet.home.arpa.' and I use this domain name, too;
> we wouldn't have the same x509 SSL certificate, because each of us uses
> its own private key ...
>
> why not just define the org. that hosts the ARPA TLD (IANA?), as the CA
> for these domains and the root certificate as built in token to the common
> browsers and/or operating systems?
> there it should only be neccessary to upload the certificate request,
> gicwn the '.home.arpa.' domain name, and an email address where the
> certificate is sent to;
> the certificate will be a wild card certificate for this .home.arpa.
> domain ..
>
> I would want this to be added as additional section to this Draft/RFC;

If you're going through all this trouble of having a central API that
will hand out certificates, wouldn't it be possible to make that same
authority hand out pseudo-random unique subdomains (of some suitable
domain; not necessarily .home.arpa)? Then you are only an NS record from
solving the globally visible naming problem... :)

-Toke

---

From: "Walter H." <[email-masked]>
Date: Tue, 1 Aug 2017 12:41:14 +0200

On Tue, August 1, 2017 11:52, Toke Høiland-Jørgensen wrote:
> will hand out certificates,

this need not neccessarily be a central API, just a sort of rules, to make
the existing CAs hand out the certificate without the need of any
authentication ...

> wouldn't it be possible to make that same
> domain; not necessarily .home.arpa)?

are you talking about a TLD e.g. ".home" which is as the other TLDs like
.com or .net or even .at with the difference, that the authoritatativ DNS
servers of such a domain needn't be accessible from internet ...; and this
registration could hand out the certificates, too;

> Then you are only an NS record from

with the thought above these aren't globally visible and there is no need to;
but the risk that a misconfiguration tells the folks the LAN structure ...

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 09:22:19 -0400

> other authentication, as these domain names need not be unique ...

In order for a PKI solution to work, it has to be possible for any given cert to apply to a unique name, the ownership of which can be defended somehow.   The CABF has spoken unequivocally on this topic:

https://www.digicert.com/internal-names.htm <https://www.digicert.com/internal-names.htm>

The point of having PKI in the homenet is so that we have secure connections between browsers and servers, and so that users aren't trained to click through certificate warnings just to get things working.   Any solution to this problem has to meet those two requirements.   And to achieve the second requirement, the CABF is going to want it to be the case that the cert identifies a specific endpoint for communication.

When I say "I don't know how to do that," this is what I'm talking about.   Actually, I do know how to do it: get a public delegation.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 09:23:05 -0400

> solving the globally visible naming problem... :)

That's what section 4 of the old homenet naming architecture document described.

https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00#section-4 <https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00#section-4>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 1 Aug 2017 14:48:23 +0000

> https://www.digicert.com/internal-names.htm

The CABF is about "publicly trusted certificates". There is no need or applicability of "publicly trusted certificates" in the context of a home network. No certificate authority in the world is capable of certifying that a device inside a specific home network actually belongs there. The only entity capable of identifying devices that belong in the home network is the home (network) owner. This isn't about public trust. It's about private trust.

In reading Stephen's email about what he did wrt certificates, what stood out to me were:
 (1) The primary goal was to stop the annoying browser warnings. [note that neither HNCP nor Babel would be expected to check against CAs stored in browsers, so they would not be subjected to this annoyance; but the annoyance is something to prevent when considering the broader "naming architecture"]
 (2) Stephen (the home network owner) was the assigner of trust. He was the root certificate authority.

We had discussed (back in Chicago) that a first step should be to figure out first what our goals were wrt "security". From the perspective of the end user, here is my starter list of considerations:
1. End users would like to know that device software / firmware has no Trojans and is "good". This is not a good fit for X.509 certificates or PKI. This would be something for some logo-based certification program (like a UL, Good Housekeeping, IPv6 Ready, etc. stamp). I think this is outside the (current) scope of homenet and there are other orgs working on this sort of thing. In any case, it has nothing to do with encryption and X.509 certificates.
2. End users are the absolute (root) authority as to what does and doesn't belong on the home network. No one else. Even in the case of "unmanaged" home networks. Verisign and others are incapable of telling me whether or not a device belongs on my home network.
3. End users want it to be very easy to add devices/services to the home network. 
4. End users want it to be very easy to remove devices/services.
5. End users want to know when devices on the home network are misbehaving, and they want to easily identify such devices.
6. End users don't want annoying "untrusted" warnings for devices and services inside the home network that they have decided to add to it.

Does this seem like a reasonable list? Are there items y'all disagree with? Others to add?
Thanks,
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 11:04:19 -0400

> The CABF is about "publicly trusted certificates". There is no need or applicability of "publicly trusted certificates" in the context of a home network. No certificate authority in the world is ca…

This distinction is meaningless, unfortunately, because it's browsers that we need to trust the network, and we absolutely do not want to install a network-specific trust anchor in every end-user browser.   Even if that were possible, it would be a gaping attack surface.

> (1) The primary goal was to stop the annoying browser warnings. [note that neither HNCP nor Babel would be expected to check against CAs stored in browsers, so they would not be subjected to this a…

(1) this isn't an issue for HNCP or babel.   It's an issue for browsers.
(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.

> (2) Stephen (the home network owner) was the assigner of trust. He was the root certificate authority.

This doesn't work because there is no grammar for ascribing different meanings to different trust anchors in browsers, as far as I know.   Attempts have been made, but it's ultimately binary: the end user doesn't perceive the difference.   Without such a grammar, we don't have a way to make Stephen the assigner of trust for his network without making him a potential assigner of trust for all networks for any device that considers him an assigner of trust.

> 1. End users would like to know that device software / firmware has no Trojans and is "good". This is not a good fit for X.509 certificates or PKI. This would be something for some logo-based certi…

I think that people are talking about code signing elsewhere in the IETF; I would say that that is where this particular problem would need to be addressed.   I think there's work here relating to TEEP, but also to just regular code signing.

> 2. End users are the absolute (root) authority as to what does and doesn't belong on the home network. No one else. Even in the case of "unmanaged" home networks. Verisign and others are incapable…

Sure.

> 3. End users want it to be very easy to add devices/services to the home network. 

Sure.

> 4. End users want it to be very easy to remove devices/services.

Sure.

> 5. End users want to know when devices on the home network are misbehaving, and they want to easily identify such devices.

Yes.

> 6. End users don't want annoying "untrusted" warnings for devices and services inside the home network that they have decided to add to it.

Yes, but s/annoying/attack-surface-generating/

> Does this seem like a reasonable list? Are there items y'all disagree with? Others to add?

I think this is a good start.

What might become interesting are the implications of this list: what it would take to actually satisfy these requirements.   :)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 01 Aug 2017 19:33:09 +0200

> (1) this isn't an issue for HNCP or babel. It's an issue for browsers.

It's an issue *with* browsers.

> (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.

Agreed.  The problem, of course, is not Homenet-specific -- I've got
exactly the same problem with my printer, or with Babelweb.  The problem,
in short, is that HTTP doesn't allow either BTN or TOFU security -- it's
either creartext of CA-based (or big red warning).

I think that Barbara expressed very clearly why the CA model is simply not
adapted to the Homenet.  I don't think we should be complicating the
Homenet protocol stack in order to work around the limitations of the
browser stack.

-- Juliusz

---

From: "Walter H." <[email-masked]>
Date: Tue, 01 Aug 2017 20:02:28 +0200

> Homenet protocol stack in order to work around the limitations of the
I'm not thinking about the homenet protocol I think of the fact that the
'.home.arpa' is the general purpose domain which can be used in home 
networks
just for simple DNS, there is nothing said about the homenet protocol at 
all;

what is the real problem having stricht rules in this Draft/RFC to get an
SSL certificate that can be used  inside such an environment;
so that no own PKI is neccessary?

by the way, when you look at the x509 certificate chain, that is used by 
intel.com
you find an intermediate, that this can only be used to sign requets for 
domains that Intel own ...
why not just having such a intermediate for '.home.arpa.' domains?
this intermediate can even be public including its private key ...

in a short time there will be no way to go over the warnings in browsers,
these will be errors, where any connection will be blocked.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 14:02:43 -0400

> either creartext of CA-based (or big red warning).

Yup.

> Homenet protocol stack in order to work around the limitations of the

Best is the enemy of good enough.   Also, you routinely overestimate how complicated this stuff is.   I appreciate that you value simplicity, but the rule I prefer to follow is: "make it as simple as possible, and no simpler."

The bottom line is that a global delegation+ACME PKI is a knob I can turn.   Fixing browsers is a knob I can't turn, and the browser vendors have spoken pretty unequivocally on this topic.   If you want to tilt at that windmill, I will gladly lend my voice, but I am not hopeful.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 14:04:04 -0400

> so that no own PKI is neccessary?

The problem is that it's not up to us to set these rules—it's up to CABF, and they have ruled on this, and (IMO) not capriciously.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 01 Aug 2017 20:37:15 +0200

> The bottom line is that a global delegation+ACME PKI is a knob I can turn.

Think of it as a knob with a wasps' nest behind it.

> Fixing browsers is a knob I can't turn, and the browser vendors have spoken
> pretty unequivocally on this topic. If you want to tilt at that windmill, I
> will gladly lend my voice, but I am not hopeful.

Thanks for the offer, but no.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 14:51:06 -0400

> Think of it as a knob with a wasps' nest behind it.

I know how to build it, so no, I don't think of it that way.   I can think much worse wasp's nests.   One example would be a network with no trust model that encourages end-users to engage in very risky practices in order simply to use it.   I don't think we can fully mitigate that problem, but I think it's worth thinking about what we _can_ do to mitigate it.

---

From: "Walter H." <[email-masked]>
Date: Tue, 01 Aug 2017 20:53:50 +0200

On 01.08.2017 20:04, Ted Lemon wrote:
> On Aug 1, 2017, at 2:02 PM, Walter H. <[email-masked] 
> <mailto:[email-masked]>> wrote:
> The problem is that it's not up to us to set these rules—it's up to 
> CABF, and they have ruled on this, and (IMO) not capriciously.

is there a problem, to have the organization that has the delegation of 
".home.arpa." also provide such SSL certificates
signed by an intermediate that got signed by any CA?

and these should be a section in this Draft/RFC ...

so that there is neither need of errors/warning neither red nor cowblue 
or other color; and also no need of having an own PKI
when not wanted to or or not having the knowledge about at all;

it would be quite strange to think that anybody that use a browser for 
electronic banking has the knowledge about SSL ...
by the way knowledge about SSL is more common than knowledge about 
DNSSEC ...

in good old german we would say: "wo ein Wille da ein Weg" or in strange 
English: "a way is open when its wanted to be open"

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 15:21:46 -0400

On Aug 1, 2017, at 2:53 PM, Walter H. <[email-masked]> wrote:
> is there a problem, to have the organization that has the delegation of ".home.arpa." also provide such SSL certificates 

This is not how PKI works.   For a browser to trust a signing authority, the signing authority has to be vetted as trustworthy.   Honestly, PKI is a bit of a dumpster fire, but the point is that adding this requirement, even if we could, would not improve the situation.   Please understand that the goal of network security, including PKI, is not to make warnings go away: it is to protect users from attacks on the  security of their information and devices.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Aug 2017 17:06:36 -0400

Ted Lemon <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Aug 2017 17:15:13 -0400

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 <[email-masked]>
wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>
>

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Aug 2017 05:21:01 +0200

On 01.08.2017 21:21, Ted Lemon wrote:
> On Aug 1, 2017, at 2:53 PM, Walter H. <[email-masked] 
>> is there a problem, to have the organization that has the delegation 
>> of ".home.arpa." also provide such SSL certificates
> This is not how PKI works.
wrong exact this is it; a PKI has at least a root CA and end entity 
certificates, and of course I never mentioned this, the browser does 
validate checks - either CRL or OCSP, and all this is meant by running a 
own PKI ....
and this is not everyones thing to have this configured ...

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Aug 2017 15:07:42 +0200

On 01.08.2017 23:15, Ted Lemon wrote:
> I addressed that question in a previous reply.   Your home network 
> does not have the equivalent security to letsencrypt.org 
> <http://letsencrypt.org>'s certificate signing infrastructure (I hope!!).
that is not the question, the question is: is it possible to use some 
self signed certificates without trust anchor installed, in the near future?
by the way how would you distinguish between LAN and WAN in an IPv6 world?
in an IPv4 world it is done by RFC1918 addresses ...
>   Installing a trust anchor means that trust anchor has signing 
> authority for any name---there's no way to install one that doesn't.
there is a way, look at this one:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

> 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.
>
exakt this was the intention of my inital thoughts