Subject: [homenet] Ted's security talk at IETF99: DNCP Security

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jul 2017 11:21:02 -0400

So I'm watching via meetecho the meeting.  Some minor comment that it seems
like many things have happened in homenet that haven't really been on the
list.  {Or maybe it was just DMARC vs ietf.org forwarding "helping" me. I've
had to whitelist the ietf.org mail servers}

The things that Ted wants, such "this the ID of the router", and the like,
and this really the topic of the ANIMA BRSKI protocol.  It can be profiled
to work in Homenet, provided that HNCP can elect a registrar.
I think that is entirely workable, btw.
I don't think that Homenet has to invent any protocols here.

Is there a document for this Ted?  I will offer to help.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 11:28:32 -0400

> Is there a document for this Ted?  I will offer to help.

Your help would be much appreciated, but I don't know why there would be an election, so there's at a minimum some thinking to do there.   There is no document yet.

Also, bear in mind that a vendor-centric approach to this probably isn't going to work, because right now all the Homenet work I'm aware of is happening on OpenWRT and LEDE.   I'm sure that will change if we come up with something vendors want to deploy, but it has to work for the prototype case too.   And there's no particular reason to think that a PKI key from a vendor makes a device trustworthy.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jul 2017 13:41:54 -0400

Ted Lemon <[email-masked]> wrote:
    mcr> Is there a document for this Ted? I will offer to help.

    > Your help would be much appreciated, but I don't know why there would
    > be an election, so there's at a minimum some thinking to do
    > there. There is no document yet.

I think that we need to have a Registrar that issues certificates.
ANIMA's BRSKI document automates much of this.

That partly gets rid of the security exception on each access to the
web interface: provided the web browser loads the new trust anchor.

    > Also, bear in mind that a vendor-centric approach to this probably isn't
    > going to work, because right now all the Homenet work I'm aware of is
    > happening on OpenWRT and LEDE. I'm sure that will change if we come up

This is where all the other pairing mechanisms come into play.
You mentioned having a laundry list of them.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 14:00:33 -0400

> web interface: provided the web browser loads the new trust anchor.

I don't know how to make that work without a fake domain tree.   Can't we just use ACME+letsencrypt.org <http://letsencrypt.org/>?

> You mentioned having a laundry list of them.

Sure.   The question is, what value does the PKI cert add here?   I agree that having a cert that validates is good for the web UI, but I don't see how it helps in establishing trust.

I would be tempted to do something like what Christian is doing with DNSSD privacy: print a QR code on the box, take pictures of all the QR codes with your smartphone, and then use your smartphone app to bootstrap trust using those QR codes.   You could do something similar by just flashing the front panel LEDs really fast when the "pair" button is pressed, and have the smartphone decode that, as is being done with exfiltration malware now.   I suspect there's code we could download... :)

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 31 Jul 2017 20:22:52 +0100

On 31/07/17 19:00, Ted Lemon wrote:
> I don't know how to make that work without a fake domain tree.
> Can't we just use ACME+letsencrypt.org <http://letsencrypt.org/>?
I think the protocols would work fine, but I'm not sure there's
a current challenge type that'd work here, for LE or any similar
service. (The current set of challenges in the acme spec is at
[1].)

For my main home router (a Turris), I setup a VPN connection so
that the AAAA for a name I control is routed to the Turris when
the VPN is up, and then I just used acme.sh [1] to talk to LE
and all that works just fine and gets rid of the annoying browser
insecurity warning when I use luci.

(I further cheat by only having that VPN up when I need to talk
to LE for renewal checks and otherwise just resolve the name
using 10/8 inside the home, but I'm sure there're better options.)

So the plumbing/protocols all do work if you have a name and
address that works from the CA service provider POV. It's just
that almost nobody can do that today.

Is this something where it'd be worth trying to get a few folks
from the various communities on a call to see if we can come up
with something that might work for the openwrt/lede type cases?

If so, I'd be happy to try set that up in a month or so, when
holliers are done and I'm supposedly gonna be a chair-like being:-)
I'd be happy to try that even if the chances of a Eureka! moment
aren't very high. (And btw, the reason I suggest that scope is
that I figure commercial device vendors can figure out the cert
issuance part just fine already, and with better assurance, but
probably have the same issues with browser trust stores as do the
openwrt/lede folks, so I'm not suggesting excluding commercial
device vendors, just limiting the scope to stuff that could be
worked on today by anyone if we did have that Eureka! moment.)

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-8
[2] https://github.com/Neilpang/acme.sh

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 15:47:34 -0400

> with something that might work for the openwrt/lede type cases?

Yes.   I actually suggested a design for solving this problem in an earlier version of the homenet naming architecture document:

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

I took this out in the -01 document because I was specifying something that probably ought to be specified in a different document—I just wanted to get it out there so that it wouldn't get patented.   I think this is something that could be done on a demonstration basis right now (modulo figuring out all the steps in the process, which I just sketched).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jul 2017 20:20:23 -0400

> I don't know how to make that work without a fake domain tree. Can't we just
    > use ACME+letsencrypt.org?

I hadn't thought about that.
The objections I can think about involves three kinds of things:
  a) do they really want this kind of traffic?
  b) the certs issued will go into their cert transparency list, and I think
     that means we lose privacy.
  c) to make it work, they have to verify things.  IPv6 makes the
     connectivity easy to arrange, but it seems like it's a big exposure for
     the device.  We are talking more than just routers... I'm thinking
     printers and all sorts of things.

    > Sure. The question is, what value does the PKI cert add here? I agree that
    > having a cert that validates is good for the web UI, but I don't see how it
    > helps in establishing trust.

It doesn't establish initial trust, it gives the user a trusted icon in their
browser once we have initial trust.

    > I would be tempted to do something like what Christian is doing with DNSSD
    > privacy: print a QR code on the box, take pictures of all the QR codes with
    > your smartphone, and then use your smartphone app to bootstrap trust using
    > those QR codes. You could do something similar by just flashing the front
    > panel LEDs really fast when the "pair" button is pressed, and have the
    > smartphone decode that, as is being done with exfiltration malware now. I
    > suspect there's code we could download... :)

I think that these are all really good ways to establish initial trust.
BRSKI mentions the whole category at:
  https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07#section-4.2

  3.  The Pledge MAY have an operational mode where it skips Voucher
      validation one time.  For example if a physical button is
      depressed during the bootstrapping operation.  This can be
      useful if the vendor service is unavailable.  This behavior SHOULD be
      available via local configuration or physical presence methods to
      ensure new entities can always be deployed even when autonomic
      methods fail.  This allows for unsecured imprint.

Christian's comments in DNSSD (which I also watched today) is right though:
for many applications in *discovery* is important you probably don't want
certs, because they reveal too much, and the relationship is too ephermeral.
The link between Dave's Laptop and Dave's Cool Printer is probably longer.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 20:55:53 -0400

>     printers and all sorts of things.

Probably they don't, although they appear to be handling rather a lot of traffic already.   The problem is, we have no way to establish trust on a domain name because the browser vendors don't support DNSSEC-based TLS certs.   For some reason.   Not that I am bitter...

> browser once we have initial trust.

Blrk.   I just don't think it's a good idea to burn certs into routers.   And I don't want the end user to be relying on their router vendor for their PKI.   But I will admit that I haven't done a thorough threat analysis, so I can't justify my collywobbles.

>    The Pledge can choose to accept vouchers using less secure methods.
>    These methods enable offline and emergency (touch based) deployment
>    use cases:

That ain't going to work.   But we can probably figure something out.

> The link between Dave's Laptop and Dave's Cool Printer is probably longer.

Indeed, but we don't want Dave's Laptop going around asking for Dave's Cool Printer when Dave's Laptop is not on the home network where Dave's Cool Printer lives.