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>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
