Re: [homenet] securing zone transfer

[Ted Lemon <[e-mail]>]

On Jun 12, 2019, at 10:22 AM, Michael Richardson <[e-mail]> wrote:
> 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.