Subject: [homenet] securing zone transfer

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Jun 2019 16:03:20 -0400

Hi,

The front end naming architecture uses a primary and a secondary dns server
to synchronize a zone. The expected exchanges are (SOA, NOTIFY, IXFR, AXFR.
We would like to get feed backs from the working group on what are the most
appropriated way to secure this channel.

Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does not
provide confidentiality, and we would rather go for user space security.
Are there any recommendation for using TLS or DTLS in that case ?

Any thoughts would be helpful.

Yours,
Daniel

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 16:35:04 -0400

> Are there any recommendation for using TLS or DTLS in that case ?

And TSIG requires the Distribution Master to have a database of private
(symmetric) keys, which if disclosed causes havok.  (yes, DNSSEC can
partially save your bacon as we propose signatures be done on the homenet routers)

Can we use RFC7858 to authorize and provide privacy for AXFR?   We don't know
yet!  I believe that SIG(0) can be used for authorization, but I've never
configured that myself, or seen it in production.

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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 7 Jun 2019 22:31:56 +0100

On 07/06/2019 21:03, Daniel Migault wrote:
> Hi,
> 
> The front end naming architecture uses a primary and a secondary dns 
> server to synchronize a zone. The expected exchanges are (SOA, NOTIFY, 
> IXFR, AXFR. We would like to get feed backs from the working group on 
> what are the most appropriated way to secure this channel.
> 
> provide confidentiality, and we would rather go for user space 
> security.  Are there any recommendation for using TLS or DTLS in that 
> case ?

Please don't invent something new.  DNS over TLS should be fine for 
channel security, with TSIG embedded inside that if additional 
authorisation is required.

Ray

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 23:36:11 -0400

> authorisation is required.

Can we get away without TSIG?

Can we use TLS for authorization, assuming that we have trusted certificates
at both ends?  Perhaps this is more of a: did anyone implement this?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Jun 2019 23:50:49 -0400

> at both ends?  Perhaps this is more of a: did anyone implement this?

How is trust established?   Sure, doing TSIG over TLS is no problem.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Sat, 8 Jun 2019 13:17:20 +0200

Ted Lemon wrote on 08/06/2019 05:50:
> On Jun 7, 2019, at 11:36 PM, Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:

Bootstrapping trust is always going to be an issue no matter what we do.

There can be multiple ways to bootstrap this, and multiple possible 
providers pre-configured in the GUI.

Possible alternatives for further investigation:

1) something burned in at manufacturing time + trust between the 
manufacturer and the DNS Outsourcing Infra provider.

An initial query from the HNA to the infra could include a proposed 
domain name e.g. an AXFR or SOA query for <hn-ULA>.example.com sent to 
the DM together with SIG(0) signing of this name.

The signing could be done by a private key held at the manufacturer.

SIG(0) doesn't protect the wrapper, only the query data, so the query 
can be signed in advance off-line before anything like the homenet IP 
address is known.

The DNS outsourcing infra can check this signature either using an 
associated public key that is hosted on the manufacturer's DNS in a 
pre-agreed location. e.g. homenet-keys.manufacturer.com. Or the 
manufacturer could pre-share this public key with the DNS outsourcing 
provider out of band.

2) Out of band sign up using a public/private key held at the DNS 
outsourcing service provider at service sign up time (https + credit 
card + CGI script on the service provider's web site -> delegated domain 
name + SIG(0) signed delegated domain name query on the HNA for the 
initial query to the DM). The DM only needs to know the current valid 
public keys used for the SIG(0), and the private key and credit card 
details can be held elsewhere and regularly rotated.

3) Trust based on the TLS + certificate chain, rather than anything at 
the DNS application level. Currently very much hand waving on my part up 
until now. I've seen DANE being able to validate TLS connections based 
on a certificate chain (e.g. RFC 6698 DANE-TA(2) Trust anchor assertion, 
with a common trust anchor like let's encrypt X3 root) and was thinking 
we could leverage that somehow for mutual authentication, along with 
perhaps DNS over HTTPS (RFC8484). On the DM end that could use standard 
TLSA records published in the parent zone to validate the DM to the HNA. 
In the other direction we'd have to somehow to process a certificate 
from the HNA to identify the manufacturer or end user to the DM. But 
that's a well-known problem in web server land.

Thoughts?

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 Jun 2019 18:32:01 -0400

> How is trust established?   Sure, doing TSIG over TLS is no problem.

Certificates are exchanged/created at manufacturing time (IDevID), and then
optionally updated to LDevID.  The certificate contains the name of the zone
which the HNA is authoritative for (or a control record pins the
certificate).

TSIG requires a shared secret, thus a database of shared secrets available
online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
if I have to use TSIG for mechanical reasons, I want to derive the secret
From the TLS.

I need to authorize the following:
  1) DNS update of some data (NS, DS, AAAA that NS points to) by
     Distribution Master (cloud/public system)
  2) SOA query by Distribution Master by HNA.
  3) AXFR by Distribution Master by HNA.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 8 Jun 2019 19:36:33 -0400

For dns updates, SIG(0) works fine. I have code you can steal that works with mbedtls and ecdsa. Signing and validation.  But I think TLS client certs can also work.  Proving the front end servers identity sounds like the hard part. 

Sent from my iPhone

> On Jun 8, 2019, at 6:32 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jun 2019 09:27:34 -0400

Ted Lemon <[email-masked]> wrote:
    > For dns updates, SIG(0) works fine. I have code you can steal that
    > works with mbedtls and ecdsa. Signing and validation.  But I think TLS
    > client certs can also work.  Proving the front end servers identity
    > sounds like the hard part.

Just to ask again clearly:

1a) is it possible to authorize an AXFR transfer by SIG(0)?
1b) is it possible to authorize an SOA query by SIG(0)?
2) is anyone doing AXFR over TLS  (DPRIVE)?

{3) is RFC3007 really the most recent text on dynamic DNS?}

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Jun 2019 12:21:16 +1000

> On 10 Jun 2019, at 11:27 pm, Michael Richardson <[email-masked]> wrote:
> 
> 

Yes.

> 1b) is it possible to authorize an SOA query by SIG(0)?

Yes.

> {3) is RFC3007 really the most recent text on dynamic DNS?}

What has changed to need a more recent RFC?  Once you can identify the
requesting party, which SIG(0) and TSIG can do, the rest is policy.

I suppose we could have DHCP clients send KEY rdata as part of the DHCP
request for DHCP servers to insert in the reverse zone when addresses /
prefixes are allocated to allow the clients to use SIG(0) UPDATE requests
to update reverse zones.  This would allow for more than PTR records to
be added to reverse zones.  I did write a I-D about this for PD but got
no traction[1].  The technique would work equally well for individual addresses.
All it really requires is a DHCP code point to be allocated.

[1] https://datatracker.ietf.org/doc/draft-andrews-dnsop-pd-reverse/

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 11 Jun 2019 13:38:43 +0200

> The front end naming architecture uses a primary and a secondary dns server to
> synchronize a zone.

People will recall that the need for a hidden primary hasn't been
established yet.  Please see my unanswered e-mail of 21 November 2018.

  https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jun 2019 09:54:35 -0400

> https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ

We strongly believe that the HNA needs to know the list of names in order to
be able to answer for those names when there is unstable (or no) Internet connectivity.

Otherwise, applications and people have to know two different names for the
service. (A public one for when away, and the .local one)

In our current draft we have:

2.1.  Alternative solutions

   An alternative to having a single zone is what is currently common
   with IPv4, where a host uses a RESTful HTTP service to register a
   single name into a common public zone.  This is often called "Dynamic
   DNS", and there are a number of commercial providers, including
   dyn.com, ghandi.com.  These solutions were typically used by a host
   behind the CPE to make it's CPE IPv4 address visible, usually in
   order to enable incoming connections.

   For a small number (one to three) of hosts, use of such a system
   provides an alternative to the architecture described in this
   document.  The alternative does suffer from some limitations:

   o  the CPE/HNA router is unaware of the process, and can not answer
      for the same names when there are disruptions in connectivity.
      This makes the home user using different names when there are
      disruptions.

   o  the CPE/HNA router can not control the process.  Any host can do
      this regardless of whether or not the home network administrator
      wants the name published or not.  There is therefore no possible
      audit trail.

   o  the credentials for the dynamic DNS server need to be securely
      transferred to the hosts that wish to use it.  This is not a
      problem for a technical user to do with one or two hosts, but it
      does not scale to multiple hosts and becomes a problem for non-
      technical users.

   o  "all the good names are taken" - current services put everyone's
      names into a some set of zones, and there are often conflicts.
      Distinguishing similar names by delegation of zones was among the
      primary design goals of the DNS system.

   There is no technical reason why a RESTful cloud service could not
   provide solutions to many of these problems, but this document
   describes a DNS based solution.

---

From: Jacques Latour <[email-masked]>
Date: Tue, 11 Jun 2019 18:59:59 +0000

Daniel,

In trying to setup our secure home gateway project to have the external zone & primary DNS server setup and managed on the gateway itself and to XFR back to secondary name servers somewhere turned out not be functional or practical, first, the gateway does not know for sure which external NS are use by the secondary DNS service, second, the IPs of the WAN port might not be the internet facing IPs and this could break inbound connectivity.  We’re looking at using dynamic DNS updates for things that need internet connectivity, and have the primary DNS server on the main land.   TSIG & DNS over TLS look like a good option to look at.

Jacques

From: homenet <[email-masked]> On Behalf Of Daniel Migault
Sent: June 7, 2019 4:03 PM
To: homenet <[email-masked]>
Subject: [EXT] [homenet] securing zone transfer

Hi,

The front end naming architecture uses a primary and a secondary dns server to synchronize a zone. The expected exchanges are (SOA, NOTIFY, IXFR, AXFR. We would like to get feed backs from the working group on what are the most appropriated way to secure this channel.

Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does not provide confidentiality, and we would rather go for user space security.  Are there any recommendation for using TLS or DTLS in that case ?

Yours,
Daniel

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jun 2019 15:13:15 -0400

> In trying to setup our secure home gateway project to have the external zone & primary DNS server setup and managed on the gateway itself and to XFR back to secondary name servers somewhere turned…

Have you looked at draft-ietf-dnssd-srp (https://tools.ietf.org/html/draft-ietf-dnssd-srp-01 <https://tools.ietf.org/html/draft-ietf-dnssd-srp-01>)?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jun 2019 20:48:00 -0400

Ted Lemon <[email-masked]> wrote:
    >for things that need internet connectivity, and have the primary DNS
    >server on the main land.   TSIG & DNS over TLS look like a good option
    >to look at.

    > Have you looked at draft-ietf-dnssd-srp
    > (https://tools.ietf.org/html/draft-ietf-dnssd-srp-01
    > <https://tools.ietf.org/html/draft-ietf-dnssd-srp-01>)?

Ted, I didn't think it was relevant, but I read it anyway.

It has been sometime since I tried to grok the SRP stuff, and last time it
was mostly to understand the more homenet related things.

  dnssd-srp> In other network environments, updates for names ending in
  dnssd-srp> "default.services.arpa" may be rewritten internally to  names with
  dnssd-srp> broader visibility.

Our goal with front-end-naming is to provide the "rewritten internally function".

I found section 2.3.2.  Testing using standard RFC2136-compliant servers out
of place. I think it belongs in an appendix?

This dnssd-srp protocol seems like it will work wonderfully within a homenet
(or small to medium sized campus). I think that is the goal.

I don't think it will work as the protocol for a homenet to publish a public
zone to the Internet without some additional security and setup. At least,
that's my feeling at this point.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Jun 2019 03:10:34 +0200

Dear Michael,

>> Please see my unanswered e-mail of 21 November 2018.

>> https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ

Thank you for your detailed reply.  I'm glad we're finally having
a discussion about my objections to Daniel's proposal.

> We strongly believe that the HNA needs to know the list of names in
> order to be able to answer for those names when there is unstable (or
> no) Internet connectivity.

> service. (A public one for when away, and the .local one)

That's a good point.  While I happen to believe that it's reasonable to
have a service known as "boombox.local" from home, and
"boombox.jch.example.org" from the Internet, this might be inconvenient
for e.g. smartphone users.

>       does not scale to multiple hosts and becomes a problem for non-

I think that's our main disagreement.

For some reason, you guys seem to be assuming that the average user will
want to publish hundreds of names in the global DNS.

However, none of the end-user services that I know use incoming
connections require a name in the global DNS to function (WebRTC, Skype,
online games, BitTorrent, remote desktops, BTSync/Resilio, syncthing).
Thus, my assumption is that the typical user will want to publish exactly
0 public names, and that only the extreme geek will publish up to 3 or 4
(music server, NAS, game server, web server with family photographs).

Richard, Daniel -- please be so kind as to explain why you think my
assumption is wrong.  How many names do you envision wanting to publish in
the public DNS, and for what purpose?

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jun 2019 21:26:31 -0400

> for e.g. smartphone users.

Actually, it's fatal, because you can't get a certificate for "boombox.local"
so you can't secure it that way.  So you always have to use the FQDN.

    > want to publish hundreds of names in the global DNS.

Hundreds?  How about two.
My son wants to publish his desktop's name so that his friend can reach his
system directly for minecraft.  I want the same.  Yes, it's native IPv6 the
whole way, but they don't know that, and they don't have to know that.

    > online games, BitTorrent, remote desktops, BTSync/Resilio, syncthing).

All of these are applications which either presently use cloud relays due to
NAT, or exchange IP addresses within the protocol.  All of these applications
are built during the IPv4 mindset of scarcity.

    > the public DNS, and for what purpose?

I think that you are living in the late 1990s IPv4 scarcity world.
The gigabit connected IPv6 home doesn't have to be like that.

I know at least twenty minor geeks who have music servers, NAS,
game server boxes and that family web server.  Yet, have no clue what
an IP address is.

Many of them have griped to me that there should be a way for them to easily
give their stuff names that they can access.  We've spoken at times of
building more mesh networks here, but what's the point if you can't give
things good names?

Anyway, you don't have to publish any names if you don't want to.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jun 2019 21:38:57 -0400

I agree. That’s not my point. I actually put some ideas for how to something similar with that piece of the puzzle in one version of the homenet naming architecture. I’ll see if I can find it. 

Sent from my iPhone

> On Jun 11, 2019, at 8:48 PM, Michael Richardson <[email-masked]> wrote:
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Jun 2019 04:03:19 +0200

> so you can't secure it that way.  So you always have to use the FQDN.

That sucks, of course, but the problem is completely unrelated to being
published in the global DNS -- the very same problem applies to names that
only appear in local MDNS.

> system directly for minecraft.  I want the same.

Your son clicks "publish name" in the Minecraft server's UI, at which
point he faces the following dialog box:

  Domain: dyndns.minecraft.example.com
  Hostname: minecraft-7ac8
  Password:

The young man considers that default values are for noobz, and edits as
follows:

  Domain: richardson-family.vanity-dyndns.example.com
  Hostname: better-server-than-dads
  Password:

After the name is published (which takes half a second), the Minecraft UI
displays a "share" icon, so that your son can publish the server's name
over UUCP, or whatever it is that them youngsters use nowadays for chatting.

Your turn now.  Could you please describe the UI that you envision?

-- Juliusz

---

From: Daniel Migault <[email-masked]>
Date: Tue, 11 Jun 2019 22:20:04 -0400

Hi Jacques,

I agree the HNA cannot generate the full zone out of the box and needs some
information such as the NS. It also needs some information to configure the
primary / secondary relation such as the the IP of what we now call the
Distribution Master. DNS update on a specific zone seems tempting
especially as it is available code for it. Though I might be biased, but i
am not sure we need TSIG. I need more thoughts.

Yours,
Daniel

On Tue, Jun 11, 2019 at 3:00 PM Jacques Latour <[email-masked]>
wrote:

> Daniel,
>
>
>
> In trying to setup our secure home gateway project to have the external
> zone & primary DNS server setup and managed on the gateway itself and to
> XFR back to secondary name servers somewhere turned out not be functional
> or practical, first, the gateway does not know for sure which external NS
> are use by the secondary DNS service, second, the IPs of the WAN port might
> not be the internet facing IPs and this could break inbound connectivity.
> We’re looking at using dynamic DNS updates for things that need internet
> connectivity, and have the primary DNS server on the main land.   TSIG &
> DNS over TLS look like a good option to look at.
>
>
>
> Jacques
>
>
>
>
>
>
>
> *From:* homenet <[email-masked]> *On Behalf Of *Daniel Migault
> *Sent:* June 7, 2019 4:03 PM
> *To:* homenet <[email-masked]>
> *Subject:* [EXT] [homenet] securing zone transfer
>
>
>
> Hi,
>
>
>
> IXFR, AXFR. We would like to get feed backs from the working group on what
> are the most appropriated way to secure this channel.
>
>
>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 11 Jun 2019 22:48:58 -0400

Hi Juliusz,

I believe the answer is similar to [1]. Regarding the number of devices we
expect, it seems hard to have exact prediction, however, if we do not make
it possible this number will likely remain zero. We need to make it easier
to have more devices.

Currently services mostly send private data to the cloud, and data is
accessed through a service hosted on that cloud. While service provider
have their own interest in doing so, it is also quite hard for individual
to set a service in the homenet and be able to access that service. It is
easy to export the video of your video camera on a public cloud, it is much
difficult to be able to access the vdeo camera from outside. This is
something we need to change.

Video camera, all sorts of sensors, light controls... there is no special
need these data goes outside your homenet.

I believe the number of devices can become quite large. I also believe that
2 would be sufficient to justify not configuring things more than once.

Yours
Daniel

[1]
https://mailarchive.ietf.org/arch/msg/homenet/NCbU4XHh0tk8HAowH5rcGEB3fOo

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 12 Jun 2019 14:35:14 +0200

Thanks for the feedback.

 > first, the gateway does not know for sure which external NS are use 
by the secondary DNS service,

Agreed. The draft needs to address how the service is boot-strapped and 
auto-configred.

 > second the IPs of the WAN port might not be the internet facing IPs 
and this could break inbound connectivity

I hope that we're going to be able to move past IP filtering as the 
primary security mechanism for this draft.

Especially in the presence of renumbering.

regards,

Jacques Latour wrote on 11/06/2019 20:59:
>
> Daniel,
>
> In trying to setup our secure home gateway project to have the 
> external zone & primary DNS server setup and managed on the gateway 
> itself and to XFR back to secondary name servers somewhere turned out 
> not be functional or practical, first, the gateway does not know for 
> sure which external NS are use by the secondary DNS service, second, 
> the IPs of the WAN port might not be the internet facing IPs and this 
> could break inbound connectivity.  We’re looking at using dynamic DNS 
> updates for things that need internet connectivity, and have the 
> primary DNS server on the main land.   TSIG & DNS over TLS look like a 
> good option to look at.
>
> Jacques
>
> *From:*homenet <[email-masked]> *On Behalf Of *Daniel Migault

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 12 Jun 2019 15:31:24 +0200

Inline. Long post.

> only appear in local MDNS.
No. They are directly related. See below.
> Your turn now.  Could you please describe the UI that you envision?

It would seem your objection can be summarized as "we don't need this". 
Correct me if I'm wrong.

To me is like saying we don't need a new routing protocol like BABEL, 
because we have loads of routing protocols already.
[for the record I strongly supported incorporating BABEL into Homenet, 
because to me it was the best choice]

Funnily enough my next door neighbor (who knows nothing about 
networking) could appreciate the use case.

He can currently control his central heating system from his smartphone. 
But he needs to pay for the rendezvous service, or has a tie in to a 
particular heating-system maintenance provider.

The use case would then be that an IoT device or local gateway device 
could use one common protocol (out of scope) to talk to the Homenet 
router, then the homenet router could publish and resolve names to 
backbone DNS infra, whilst the app developer wouldn't need the 
rendezvous service or NAT traversal. The rendezvous service is also a 
single point of attack for large scale DDOS, and also might raise 
privacy concerns because the manufacturer can monitor detailed use of 
all the devices they've sold. Mobile devices could use one single name 
to connect to the gateway device in a secure manner from anywhere.

So rather than being forced to use the manufacturer's thermostat, or 
sign a service contract from a particular maintenance provider tied to 
the manufacturer, he can use OpenTherm, and he can control OpenTherm 
from anywhere.

Yes, there are HTTP REST interfaces to accomplish this, but they ain't 
standard, and they ain't always easy to use.
[check out comments from people who've tried to automate this for 
multiple alternative REST-based providers]

Yes, each individual device could also manage names directly with 
multiple DNS outsourcing providers, but then you potentially create an 
explosion of keying and signing material if you want DNS-SEC to work in 
any meaningful way.

Especially as DNS is becoming more of a trust anchor for other services.

How much easier is it to trust devices using TLS over a self-signed 
certificate anchored via TLSA records to DANE on your own DNS zone?

accept TLS from any devices with certificates with CN 
*.<my-zone>.homenet.com
accept TLS from any devices with certificates with CN 
*.<my-friends-zone>.homenet.com
deny all

Then the minecraft connection with your friend can be properly secured 
without resorting to chat protocols and shared secrets or IP filters.

You don't need to pay a CA for any magic beans because DANE will work 
with self-signed certificates, even in a chain (mode 2 trust anchor). 
And you can be sure no-one has messed with the certificate, because 
you've created the certificate yourself, and you've signed the DNS zone 
yourself with your own private keys that haven't been shared with anyone 
else. Sure, you still have to bootstrap all of this.

To me it seems obvious that people should be able to distribute services 
(if they want to) to their own network.
If they want to rely on the handful of technology giants for their 
security, then fair enough. But they should have a choice.

regards,
RayH

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Jun 2019 10:22:20 -0400

> Domain: dyndns.minecraft.example.com

And where does the password come from?
If this is one he picks, how can I know that it's a good one?
And how do I prevent him from doing this?

    > Your turn now.  Could you please describe the UI that you envision?

The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames)
is presented to the house owner, they click on the ones that the want to
be publically visible.  (They may also apply a security policy for access,
but that's not a naming issue)

There are no passwords.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jun 2019 10:42:55 -0400

> There are no passwords.

Yes please.

Juliusz, what you are saying is what you said to me when I did the original homenet naming architecture, which you said was too heavyweight.  There seemed to be consensus in the room for dropping this, and so we did.   But as time has gone by, it’s become more and more clear to me that even though this use case does not apply to every device in the home, it is a use case that applies in a significant number of cases.

We can of course build this from ad-hoc, non-standardized tools like dyndns.   We can insist that anyone who wants to address this use case has to either be a security expert, or be vulnerable.   Or we can figure out a clean way to do it using the building blocks we already have: HNCP, DNS Update, DHCP PD, etc.   And then we can write a standard that describes how to do that, and see how much uptake it gets in the real world.

I would also like to point out that in addition to Ray’s point about DANE, being able to publish an external name means that you can get a cert from Lets Encrypt.   And _that_ means that we can close the frustrating gap that we have now with home network security, which is that the web UI isn’t secure.   And we can do this with any browser, not just with browsers that support TLSA (which, unfortunately, are rare as hen’s teeth).

I’d like to also point out that one of your objections was that implementing something like the Service Registration Protocol would be too hard, and too heavy.  It turns out to fit into 12k of code space in a constrained device operating over 802.15.4.   The SRP proxy is a bit larger, but quite reasonable.   The code for both is on the hackathon github repo, and is under active development (but works at present):

https://github.com/IETF-Hackathon/mDNSResponder <https://github.com/IETF-Hackathon/mDNSResponder>

The README file only talks about the Discovery Proxy, but the ServiceRegistration subdirectory contains a complete simple service registration client: srp-simple.c
It also includes a registration proxy: srp-gw.c

Getting the SRP gateway to talk to a front-end naming primary would be very simple.   Getting AXFR to work in either direction would be as well.   It’s just a service, after all.

---

From: MIchael Thomas <[email-masked]>
Date: Wed, 12 Jun 2019 11:18:19 -0700

On 6/12/19 7:42 AM, Ted Lemon wrote:
> On Jun 12, 2019, at 10:22 AM, Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> There are no passwords.
>
> Yes please.
>
>
Speaking of which, should we be encouraging router vendors to implement 
webauthn? Considering that probably half of home routers have the 
default password, that seems like it would be a Good Thing.

I do wonder what the implications are for enrollment.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Jun 2019 15:13:03 -0400

> webauthn? Considering that probably half of home routers have the default
    > password, that seems like it would be a Good Thing.

We have done an enrollment system which based upon BRSKI.
It is described in draft-richardson-ietf-anima-smarkaklink.
We have running code with a desktop acting as the client, with
the mobile app being built now.  I am making a screencast today, actually.
There are similarities to some profiles of EAP-NOOB, but we do
rely on the manufacturer as the root of trust.

I guess we could/should have considered enhancing webauthn instead; I have to
think a bit about whether it would have work as well.  I will need to see.

At the end of the day, we wind up with a mobile phone with a certificate
enrolled into a private CA on the router.  The router itself has a
LetsEncrypt certificate acting as it's IDevID, although this could
be a private CA instead.  There are issues in both directions.

Secondary admins are encouraged to guard against loss/destruction of mobile
phone, and it is also possible to enroll a second time, provided the
manufacturer agrees (this is both a feature and a bug)

The code is at https://github.com/CIRALabs/

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jun 2019 12:38:48 -0700

> The code is at https://github.com/CIRALabs/

I'm not sure we're talking about the same thing? I'm just talking about 
the normal web interface that home routers have to hand configure them. 
There's no need for certs at all.

I wrote a blog post which considered the enrollment problem of a 
webauthn-like protocol (way before webauthn was even started). I'm not 
sure if it works for the special case of a home router though.

http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

Enrollment, of course, is out of scope for webauthn, per se.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Jun 2019 18:18:44 -0400

> I'm not sure we're talking about the same thing? I'm just talking about the
    > normal web interface that home routers have to hand configure them. There's
    > no need for certs at all.

Yes, that's what I'm talking about.
Yes, there is a need for strong security.

The bad guys are inside already, they send trojans, and if the router has
passwords ("admin"/"admin"), then the bad guys just change the security
policy.

They don't do this now, because they don't need to, our home routers are
basically swiss cheese in the outbound direction, but I'm sure they will
learn.  Particularly, it will be easy if we have a standard (or
defacto-standard) API.  At this point, the luci interface is probably easily
automated.

Modern browsers practically don't let you even type passwords in over HTTP
now, so you really really really need a certificate for the inside of the
router, and it needs to be valid.

    > webauthn-like protocol (way before webauthn was even started). I'm not sure
    > if it works for the special case of a home router though.

    > Enrollment, of course, is out of scope for webauthn, per se.

I'll read it.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jun 2019 15:35:13 -0700

> router, and it needs to be valid.
Oh, sorry, I wasn't thinking about TLS. Obviously you need server certs 
for that. I was thinking about the client side authentication which is 
what webauthn is for, and it doesn't require certs of any kind, iirc.
>      > Enrollment, of course, is out of scope for webauthn, per se.
Thanks, it's probably pretty dated by now, especially all of the crypto 
hackery :). The thing that I'm not sure about is whether the out-of-band 
method for adding clients would work in a home router situation. My 
solution required the server (ie, the router) to send email to somebody. 
It could be sms too, but it's not very clear that email from a naked 
router ip address would be very effective since, like, nobody accepts 
email from home net ranges. I guess in theory you could configure an 
mail account for the router, but that seems sort of like a non-starter. 
But there may be other ways to finesse this.

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 13 Jun 2019 01:22:28 +0200

> It would seem your objection can be summarized as "we don't need this". Correct me if I'm wrong.

No, my objection is that I cannot see how that can work in a decentralised
manner -- with no central Homenet controller.

> To me is like saying we don't need a new routing protocol like BABEL, because we have loads of routing protocols already.
> [for the record I strongly supported incorporating BABEL into Homenet, because to me it was the best choice]

When we argued between Babel and IS-IS, we were deciding between two
decentralised protocols.  In some sense, we were having an argument among
friends -- had someone suggested we use a central SDN controller instead
of a distributed routing protocol, we'd probably have ganged on the culprit.

If that's okay, I'll give a more detailed description of my objection as
a followup to MCR's comment, since the two of you are saying very roughly
the same thing.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 13 Jun 2019 01:58:19 +0200

> be publically visible.

Are you assuming here there's a central Homenet controller that presents
a web interface where the "house owner" can choose which names get
published?

Daniel's original draft used the term "CPE" for the hidden primary.  At
the time, I pointed out two things:

  - there's no single CPE in Homenet, there's zero, one or more edge
    routers which might or might not be ISP-controlled devices;
  - no Homenet service should be bound to an ISP-controlled device.

I believe that these requirements still reflect WG consensus.

Assuming that I'm right, I can only see two ways to provide global naming
without giving up on the properties above:

  - we avoid relying on a central controller (hidden primary with web
    interface);
  - we define a way to elect the central controller (hidden primary)
    in a way that doesn't bind the election to an ISP-controlled device.

(Am I missing a third option?)

The protocol that I have outlined is certainly not perfect, but it has the
virtue of avoiding the need for a central controller in the Homenet by
outsourcing naming using an end-to-end protocol between the host being
named and an external DNS primary.

I'm probably missing something, Michael, so please explain if you agree
with the analysis above, whether you're assuming a central controller,
and, if so, where is the central controller located in a network that has
multiple edge routers.

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Jun 2019 21:25:32 -0400

> a web interface where the "house owner" can choose which names get

No, we are assuming that there are one or more homenet routers that either
come with a delegated domain from the manufacturer (probably a very ugly
one), or which that CPE's ISP will delegate via DHCPv6. (or both)

Whether we should or have to do some negotiation over HNCP if there are
multiple CPEs is a problem we can deal with later.

We have, however, been thinking about the problem of having partial
connectivity for the home, and how do published names get resolved.

    > and, if so, where is the central controller located in a network that has

If an end user wants a non-ugly domain, and they buy it, then they need to
introduce one or more of their CPEs to the upstream provider of the
domain.  It could be it is at this point that it makes sense to do some HNCP,
but in essence, this is an internal problem, and the front-end-naming
document is not about internal issues.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 13 Jun 2019 14:32:16 +0200

> document is not about internal issues.

Indeed this draft should say as little as possible about what should 
happen internally (whether there's one elected central Homenet 
controller for all ISP uplinks, or there's something running on all 
Homenet routers that updates an edge HNA per ISP uplink, or the HNA 
service runs on a host, or something else).

Probably the text isn't in that state yet.

The facts of life with using DNS are that:
- a zone delegation is built on a hierarchical name space with a single 
root;
- a delegated zone is a proper subset of a parent zone,
- zone signing occurs with one single active zone signing key signing 
the complete set of RR's in a zone (not a key or signature per RR), and 
where
- zone transfer updates are performed with a master/slave arrangement 
with a limited number of known peers per zone.

If you want individual hosts to interact directly with an outsourced 
name service based on DNS (instead of via an HNA), you either have to 
delegate the zone signing to the outsourced name service (which 
introduces a different trust model), or you assign a dedicated zone per 
host (possible?), or you introduce a massive key sharing and signing 
problem.

Another use case could be small companies who want to run something like 
Active Directory on premises (AD integrated DNS).

Then they could potentially build AD forest trust relationships between 
companies.

AD of course runs on a domain controller (DC). The DC function could 
then potentially take on the role of HNA, whether that is running a 
separate server or on a CPE.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Jun 2019 10:18:10 -0400

Michael Thomas <[email-masked]> wrote:
    > method for adding clients would work in a home router situation. My solution
    > required the server (ie, the router) to send email to somebody. It

Or SMS. Or a push notify, which would definitely work.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 08:15:42 -0700

> Or SMS. Or a push notify, which would definitely work.

All of which require authentication of some form, which the router 
itself doesn't have the credentials. But home routers do have a few 
different characteristics: proximity and local addressing. Maybe your 
work you pointed out might be applicable?

Of course, it could always have a bluetooth-esque "pairing" button to 
enroll devices that are allowed to log in, but that would require hardware.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 11:47:24 -0400

On Jun 13, 2019, at 11:15 AM, Michael Thomas <[email-masked]> wrote:
> All of which require authentication of some form, which the router itself doesn't have the credentials. But home routers do have a few different characteristics: proximity and local addressing. Maybe your work you pointed out might be applicable?

“how you are connected” plus “no conflict” is a fairy effective ad-hoc method for establishing trust.

E.g., for a very long time, ISPs have used the fact that you are connected to their network as a basis for authorizing your DHCP transaction.   If the ISP is doing the front-end naming, then that mechanism could work here as well.   If someone else is doing front-end naming, then you probably have to have put a credit card in somewhere…

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 13 Jun 2019 19:39:45 +0200

> one), or which that CPE's ISP will delegate via DHCPv6. (or both)

I see.  (I still disagree with the technical choices, especially that of
binding the domain with either the manufacturer or the ISP, but now I see
a little better where you're coming from.)

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 11:33:46 -0700

On 6/13/19 8:47 AM, Ted Lemon wrote:
> On Jun 13, 2019, at 11:15 AM, Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
> E.g., for a very long time, ISPs have used the fact that you are 
> connected to their network as a basis for authorizing your DHCP 
> transaction.   If the ISP is doing the front-end naming, then that 
> mechanism could work here as well. If someone else is doing front-end 
> naming, then you probably have to have put a credit card in somewhere…
>

Yeah, the router clearly knows whether something is on the local net, 
but it doesn't know if it's a visitor. Requiring that you put the 
visitors on a guest net is not exactly ideal either.

I'm thinking that a lot  of my hand-wringing here is only for adding 
more devices to the router's list of devices that can log in. I'd assume 
that the router would be in "peer mode" by default when it doesn't have 
any enrolled devices. Worst case, you can always log into the router 
with the primary device and press a button to permit other devices. 
Which is to say, I may be overthinking this :)

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 14:37:57 -0400

On Jun 13, 2019, at 2:33 PM, Michael Thomas <[email-masked]> wrote:
> Yeah, the router clearly knows whether something is on the local net, but it doesn't know if it's a visitor. Requiring that you put the visitors on a guest net is not exactly ideal either.
> 
> 
That’s not relevant for front-end naming.   In this case the trust is being established between a customer edge router or a service on the customer network, and a front end name server operated by the ISP.   A guest device would not be able to interpose itself in this process if it were designed correctly.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 11:40:49 -0700

On 6/13/19 11:37 AM, Ted Lemon wrote:
> On Jun 13, 2019, at 2:33 PM, Michael Thomas <[email-masked] 
> That’s not relevant for front-end naming.   In this case the trust is 
> being established between a customer edge router or a service on the 
> customer network, and a front end name server operated by the ISP.   A 
> guest device would not be able to interpose itself in this process if 
> it were designed correctly.
>
>
Are we talking about the same thing? I'm not sure what naming has to do 
with dealing with crappy/default passwords on router web interfaces?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 14:46:01 -0400

On Jun 13, 2019, at 2:40 PM, Michael Thomas <[email-masked]> wrote:
> Are we talking about the same thing? I'm not sure what naming has to do with dealing with crappy/default passwords on router web interfaces?
> 
If your router has a name, it can get a cert.  If it doesn’t have a name, it can’t.   That cert then becomes a basis for establishing trust.

In the case of devices on the home network establishing trust with the router, you have to bootstrap that somehow.   In that case, the easiest thing to do is as I suggested: 

you have access to the router’s network
nobody else has established trust yet

This isn’t ideal, but it creates a pathway for further trust establishment: once you have one device that has a trusted key, then that device can authorize additional devices, which can authorize additional devices.   A device that comes onto the network after initial trust establishment can’t get trust without being approved.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 11:57:30 -0700

On 6/13/19 11:46 AM, Ted Lemon wrote:
> On Jun 13, 2019, at 2:40 PM, Michael Thomas <[email-masked] 
>> Are we talking about the same thing? I'm not sure what naming has to 
>> do with dealing with crappy/default passwords on router web interfaces?
>>
> If your router has a name, it can get a cert.  If it doesn’t have a 
> name, it can’t.   That cert then becomes a basis for establishing trust.
I'm not sure what a router cert has to do with webauthn, other than 
enabling TLS as Michael pointed out. But even self-signed cert where you 
ignore the scary warning would work too.
>
> In the case of devices on the home network establishing trust with the 
> router, you have to bootstrap that somehow.   In that case, the 
> easiest thing to do is as I suggested:
>
>  1. you have access to the router’s network
>  2. nobody else has established trust yet
>
>
> This isn’t ideal, but it creates a pathway for further trust 
> establishment: once you have one device that has a trusted key, then 
> that device can authorize additional devices, which can authorize 
> additional devices.   A device that comes onto the network after 
> initial trust establishment can’t get trust without being approved.
>
Yes, that's what I mentioned too. So I think we're in agreement.

The meta-question is whether there is something to be done here, and if 
this wg is the right place to do it. I know there was a security part of 
the charter... it sure would be nice to set an example for all of this 
IoT mischief on how to do a proper web login interface.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 15:02:08 -0400

On Jun 13, 2019, at 2:57 PM, Michael Thomas <[email-masked]> wrote:
> The meta-question is whether there is something to be done here, and if this wg is the right place to do it. I know there was a security part of the charter... it sure would be nice to set an example for all of this IoT mischief on how to do a proper web login interface.
> 
> 
This is a general problem, not an IoT problem.  IoT is a good motivating use case, not the complete problem.   We’ve talked about working on this problem here before. I think it’s in scope and this is a good place to do it.  Iff people are willing to participate!

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 12:11:17 -0700

On 6/13/19 12:02 PM, Ted Lemon wrote:
> On Jun 13, 2019, at 2:57 PM, Michael Thomas <[email-masked] 
>> The meta-question is whether there is something to be done here, and 
>> if this wg is the right place to do it. I know there was a security 
>> part of the charter... it sure would be nice to set an example for 
>> all of this IoT mischief on how to do a proper web login interface.
>>
>>
> This is a general problem, not an IoT problem.  IoT is a good 
> motivating use case, not the complete problem.   We’ve talked about 
> working on this problem here before. I think it’s in scope and this is 
> a good place to do it.  Iff people are willing to participate!
>
>

Should I write up a draft? It would be really good that something 
(convergent) evolved out Stephen, Paul and my rfc 7486, as the first 
thing I experimented on was something for a home router based application :)

Mike, who has no idea if the webauth folks had any idea about our hoba 
stuff.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 15:18:10 -0400

TBH I don’t know anything about OBA other than that I heard it discussed.  If you want to write up a draft, that can’t hurt.   I’m not promising to support it—it depends on what you come up with.   But it’s always good to have a place to start, and something to pick apart and fix up.   So by all means, if you are willing to proceed on that basis, I think it’s a good idea, and I will read it.

> On Jun 13, 2019, at 3:11 PM, Michael Thomas <[email-masked]> wrote:
> 
> 
> 
>> On Jun 13, 2019, at 2:57 PM, Michael Thomas <[email-masked] <mailto:[email-masked]>> wrote:
> Should I write up a draft? It would be really good that something (convergent) evolved out Stephen, Paul and my rfc 7486, as the first thing I experimented on was something for a home router based application :)
> 
> Mike, who has no idea if the webauth folks had any idea about our hoba stuff.
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 12:40:37 -0700

On 6/13/19 12:18 PM, Ted Lemon wrote:
> TBH I don’t know anything about OBA other than that I heard it 
> discussed.  If you want to write up a draft, that can’t hurt. I’m not 
> promising to support it—it depends on what you come up with.   But 
> it’s always good to have a place to start, and something to pick apart 
> and fix up.   So by all means, if you are willing to proceed on that 
> basis, I think it’s a good idea, and I will read it.

I don't think this needs to be very involved. I would think that a short 
bcp which lays out why webauthn is a huge advance, and a set of 
different enrollment mechanisms that have some vetting would probably be 
enough.

Mike, it's been a while since i've written a draft...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 15:43:05 -0400

On Jun 13, 2019, at 3:40 PM, Michael Thomas <[email-masked]> wrote:
> I don't think this needs to be very involved. I would think that a short bcp which lays out why webauthn is a huge advance, and a set of different enrollment mechanisms that have some vetting would probably be enough.

You mean so that we can pick one?   :)

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 12:46:27 -0700

On 6/13/19 12:43 PM, Ted Lemon wrote:
> On Jun 13, 2019, at 3:40 PM, Michael Thomas <[email-masked] 
>> I don't think this needs to be very involved. I would think that a 
>> short bcp which lays out why webauthn is a huge advance, and a set of 
>> different enrollment mechanisms that have some vetting would probably 
>> be enough.
>

Possibly, but I think there are hardware based solutions (eg "press to 
pair") and pure software based ones. The main point is to have something 
to point vendors at. They are probably clueless that this is a 
possibility now.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 15:51:09 -0400

On Jun 13, 2019, at 3:46 PM, Michael Thomas <[email-masked]> wrote:
> Possibly, but I think there are hardware based solutions (eg "press to pair") and pure software based ones. The main point is to have something to point vendors at. They are probably clueless that this is a possibility now.
> 
> 
Ah.  I don’t think that would be useful.  The “if we spec it, they will build it” approach has been an utter failure thus far.  We should have a clear use case and a clear solution that addresses that use case.  We should not specify the kitchen sink and let them pick.  If someone has a use case we didn’t address, then that’s demand to address another use case, and we can do it, but we have to be real about this.  Right now, the only use case that really matters is OpenWRT, because that is where _all_ of the running code is.   So a solution that works there is the place to start.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 13:08:33 -0700

On 6/13/19 12:51 PM, Ted Lemon wrote:
> On Jun 13, 2019, at 3:46 PM, Michael Thomas <[email-masked] 
>> Possibly, but I think there are hardware based solutions (eg "press 
>> to pair") and pure software based ones. The main point is to have 
>> something to point vendors at. They are probably clueless that this 
>> is a possibility now.
>>
>>
> Ah.  I don’t think that would be useful.  The “if we spec it, they 
> will build it” approach has been an utter failure thus far.  We should 
> have a clear use case and a clear solution that addresses that use 
> case.  We should not specify the kitchen sink and let them pick.  If 
> someone has a use case we didn’t address, then that’s demand to 
> address another use case, and we can do it, but we have to be real 
> about this.  Right now, the only use case that really matters is 
> OpenWRT, because that is where _all_ of the running code is.   So a 
> solution that works there is the place to start.
>
>
A hardware based solution is always going to be more secure than a 
software-only solution but obviously that has even less likelihood of 
being deployed. I'd be perfectly happy to write in the draft that 
hardware assisted solutions would enhance security, but they are out of 
scope, leaving exactly one recommendation for a software solution.

The thing about webauthn is that almost all of the heavy lifting is done 
browser-side. The server side code is very straightforward: store public 
keys of people who can log in, and verify them when they do. And I do 
know this from experience, albeit not with webauthn specifically.

It would be good to do this on openwrt, that's for sure. I've never 
tried to hack on it, but it can't be too horrible.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2019 16:16:36 -0400

On Jun 13, 2019, at 4:08 PM, Michael Thomas <[email-masked]> wrote:
> It would be good to do this on openwrt, that's for sure. I've never tried to hack on it, but it can't be too horrible.
> 
> 
It’s dead easy if you have a Linux VM.   Just build a package, and have a place it can be downloaded from.   When you make changes, update the package.   You can debug using gdbserver.   Let me know if you need help with this.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jun 2019 13:21:59 -0700

On 6/13/19 1:16 PM, Ted Lemon wrote:
> On Jun 13, 2019, at 4:08 PM, Michael Thomas <[email-masked] 
> It’s dead easy if you have a Linux VM.   Just build a package, and 
> have a place it can be downloaded from.   When you make changes, 
> update the package.   You can debug using gdbserver. Let me know if 
> you need help with this.
>
>
Oh, ok. This is a lot easier because it doesn't care how many real 
interfaces you have, etc. You just need to modify the backend web login, 
and insert some js into the login page which can probably been snarfed 
off the net easily enough now.

Mike

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 28 Jun 2019 14:35:28 +0200

Hi,

Ted made a valid point about "running code" in this thread.

So I've been experimenting with various configurations.

My conclusions:

1) We definitely need to properly secure communication between the HNA 
and the DM for control traffic.

This needs to be an explicit part of the draft.

2) Authentication based on the physical connection, plus source IP 
address, plus correlation of the source address against the contents of 
the RR *might* be sufficient for transactions between the HNA and the DM 
for reverse zones - all communication is guaranteed to be contained 
within a single AS.

Current best practice of using IP ACL's + BCP 38 for filtering 
communication could work in this case. The DM would then check whether 
the contents of the PTR updates arrived from a source address associated 
with the HNA.

We'd need to add some text saying the HNA should select source addresses 
for reverse zone updates appropriately (to make sure the updates came 
from an address issued via IA-PD from this ISP).

3) for communication between the HNA and a DM for forward zones, we 
definitely need to specify something stronger, because the DM 
potentially has to serve HNA's scattered over the entire Internet.

4) TSIG isn't going to scale operationally IMHO.

Too many keys to manage. Keys have to be stored on line within the DM. 
Losing keys means compromising the whole service, and it is difficult to 
recover from.

5) SIG(0) has similar problems.

Bootstrapping the trust might mean the expiration time would have to be 
so large that replay attacks will come into play.
And recovery is difficult.

6) DNS over an existing standard FOO secure transport looks promising.

The amount of traffic arriving at a DM should not be so large or time 
critical as the traffic to the resolvers, and capacity can be scaled by 
increasing the numbers of DM's.

There is also existing front-end hardware acceleration available. So the 
secure transport could theoretically be terminated on an dedicated 
acceleration box, and the DM only then needs to speak native DNS.

7) DNS over TLS can almost certainly be made to work without any new 
standards, but it will require extensive coding as support seems pretty 
limited off the shelf.

It also has the added benefit that client authentication can be built 
into the transport.

So I've been playing around with the DM being authenticated by public 
certificates to the HNA (HNA would incorporate root certificates burned 
in at the factory), and the HNA being authenticated to the DM by a 
client-specific certificate that is signed using a self-signed 
intermediate CA certificate from the DM. The DM then trusts the 
certificates it has issued to the client HNA's simply by installing the 
root CA cert on the DM: there's no client specific configuration required.

Since the HNA anyway has to be configured to use the DM, and some trust 
has to be  established, I don't see this as an onerous burden in the 
sign up process.

8) DNS over HTTPS doesn't bring us anything extra in this case IMHO.

It actually presents additional challenges with coding alternate 
transports and parsing (POST or GET HTTP1.1 HTTP2) etc.
Others may disagree, so the draft could use a "recommend DNS over TLS"

9) IMHO we should also standardize the trust-booting process into a JSON 
file, that can either be fetched via HTTPS or pasted into the HNA.

This for the same reasoning for inter-operability that DNS standardized 
the file representation of the zone file in RFC1035 Section 5.

For a start, I came up with the following, although I'm sure we can 
improve as we get more experience in what parameters are needed for each 
implementation.

I came up with 4 parameters:

dm_axfr    fqdn of the DM for axfr (so the HNA can apply IP filters on 
inbound requests)

dm_ctrl    fqdn of the DM for ctrl (so the HNA can send updates to the 
DM control channel e.g. if the HNA renumbers it would send an NS record 
and AAAA record update)

zone    the zone that is being delegated

hna_certificate    client certificate encoded as a single line with 
literal '\n' replacing cr and lf characters (common practice in existing 
equipment when pasting certificates)

This would also work for a reverse zone, although obviously it's a 
different DM etc.

Sample:

{"dm_axfr":"dm.homenetdns.com","dm_ctrl":"dm.homenetdns.com","zone":"sub.homenetdns.com","hna_certificate":"-----BEGIN 
CERTIFICATE-----\nMIIDSzCCAjMCFGy+Htuv9ErWhDkwvFU8mzocStmTMA0GCSqGSIb3DQEBCwUAMIGm\nMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQgQnJhYmFudDESMBAGA1UEBxMJ\nRWluZGhvdmVuMRMwEQYDVQQKEwpIb21lbmV0IFdHMRkwFwYDVQQLExBIb21lbmV0\nIEhOQSBEZW1vMRowGAYDVQQDExFkbS5ob21lbmV0ZG5zLmNvbTEfMB0GCSqGSIb3\nDQEJARYQdHJhc2hAZ2xvYmlzLm5ldDAeFw0xOTA2MjYwNzMyNTVaFw0yNDA2MjQw\nNzMyNTVaMB0xGzAZBgNVBAMTEnN1Yi5ob21lbmV0ZG5zLmNvbTCCASIwDQYJKoZI\nhvcNAQEBBQADggEPADCCAQoCggEBAMRQaLn7+WLhm80//Wl3gKqcDwEJrJfNM+gm\n+fpHdR2Ec15DxPoaL2wBP2bnvVu5mJGO8EC03fD9ZvFAJ46kD+K79JBMdpV4r+fO\ny/PeajXIV3pwW7mPxNyfI2N2xCwtBIps9neTZhQVTivpgvLeCyhiyoMeELca6BVg\nTB6B7R/IDlAbwEPuVesw5xzErulrbzvl/K2diTJyAega+c8uSQMLDWN72u4F98s+\nfePINqnkKJ3a9FNPVA7QBUmLBWIEVdnKuat7oAR5iveOqj9KIjBzMOsw4jCmt25F\nXRHtO0LSUE0SVtg49nuCClyBxAgdbcpuDnJXieC46jXy7OS0v6UCAwEAATANBgkq\nhkiG9w0BAQsFAAOCAQEAGm7WhvgN5QEwL5+nqx/hV05yNPAGS8be9ZHQwv+33fIU\n4BdBrQatFdV+IIUByOYpkJ1j9oxzXxm2f8QpZhZyJCPvVeJCmH3wOn2RVwFQHxix\n0VfQWVWSkW5N+o5itue3e6Toc0TPkHCEq0VfLJCbfJpZJ6wkwc/PYA/SK1ThAJY0\nlkFN9xtPwOm6Jm8L8jFe3FQMDT0oDsJOmWkud4ziRx3g10P5JZ0toShK6EdCSU1W\nCGiYCI9eaRzXJfVOH/jnjDJneAfp3ad0MKTcTFMplpjibkahmCnW9XcIentRP7mu\n0zC9KEHHRDJM8HiivyB0RaI9vmKc08MBThU0OBvJgQ==\n-----END 
CERTIFICATE-----\n"}

Thoughts?

Daniel Migault wrote on 12/06/2019 04:20:
> Hi Jacques,
>
> I agree the HNA cannot generate the full zone out of the box and needs 
> some information such as the NS. It also needs some information to 
> configure the primary / secondary relation such as the the IP of what 
> we now call the Distribution Master. DNS update on a specific zone 
> seems tempting especially as it is available code for it. Though I 
> might be biased, but i am not sure we need TSIG. I need more thoughts.
>
> Yours,
> Daniel
>
> On Tue, Jun 11, 2019 at 3:00 PM Jacques Latour <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Daniel,
>
>     external zone & primary DNS server setup and managed on the
>     gateway itself and to XFR back to secondary name servers somewhere
>     turned out not be functional or practical, first, the gateway does
>     not know for sure which external NS are use by the secondary DNS
>     service, second, the IPs of the WAN port might not be the internet
>     facing IPs and this could break inbound connectivity.  We’re
>     looking at using dynamic DNS updates for things that need internet
>     connectivity, and have the primary DNS server on the main land. 
>      TSIG & DNS over TLS look like a good option to look at.
>
>     Jacques
>
>     *From:*homenet <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Daniel Migault
>     *To:* homenet <[email-masked] <mailto:[email-masked]>>
>     The front end naming architecture uses a primary and a secondary
>     dns server to synchronize a zone. The expected exchanges are (SOA,
>     NOTIFY, IXFR, AXFR. We would like to get feed backs from the
>     working group on what are the most appropriated way to secure this
>     channel.
>
>     Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does
>     not provide confidentiality, and we would rather go for user space
>     security.  Are there any recommendation for using TLS or DTLS in
>     that case ?
>
>     [email-masked] <mailto:[email-masked]>