Re: [homenet] securing zone transfer

Inline. Long post.

Juliusz Chroboczek wrote on 12/06/2019 04:03:
>> 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.
> 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.
No. They are directly related. See below.
>>> 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.
>> 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.
> 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

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

>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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