Some 22cents here (Cc'ing ANIMA/IOTOPS):
I think we should foremost distinguish between two main use-case arenas:
A) In one set of use-cases, we can and want to create muggle friendly
names for devices,
except that those are (for debatable reasons) not global and hence we can
not use off-hand
our pre-existing WebPKI approach to authenticate name ownership.
B) In another set of use cases we can not or we do not want/need to create
muggle friendly
names for devices - but we still want to use TLS to talk to them. And
(alas) browsers.
For example https://_NPNE4IG2GJ4VAL4DCHL64YSM5BII4A2X.printer.local (from
Martin Thomsons doc,
i'll call it "Martins URL") is IMHO not muggle friendly. It totally
violates the whole WebPKI
idea that a muggle can feel safe that it is talking to the right/desired
device via its browser.
Heck. You do indeed need magic for the WebPKI assertion (i am talking to
the right device) to hold
true for such domain names.
It seems all the existing approaches proposed to far are A), and some at
least seem
to think that Martins URL is suitable for A). And i think neither is true.
I for once would be very happy if we first had a solution for B).
In ANIMA for example, we do deal with CPE that come with certificates
(IDEVID), and
if a user is crazy enough to talk to such a device (in that IDEVID-only
state) via a browser,
then that user is not a muggle, but an experienced network operator, so
Martins URL
would actually be oki (because the experienced network operator would not
rely only on the
domain name in the browser address field).
A muggle instead (of a browser) is typically given an "App" (see "google",
"apple" store)
to talk to these devices and those apps would be able to take away the
problems of Martins URL.
The muggle would never need to see it. Except that the poor developer of
such an App is today
faced with TLS libraries that mandate the use of WebPKI certificates to
even allow you to
use TLS. Which strikes me as completely silly when i do not want to.
Even assuming the wishfull thinking case of an app that can help me deal
with a variety
of vendor devices not belonging to a specific SDO realm (like not limited
to thread or
othrer SDOs solution that may have come up with more specific solutions):
An app could
perfectly well know/find trustworthy root-CA for all the relevant CA of
all the
relevant vendors. And if that's a problem, then we can figure out a DNS
scheme to
carry those root CA certificates of IOT vendors in DNS to find them
easier. But: there
seems to be no easily useable TLS library to let go of the WebPKI domain
name validation
and replace it with a list of vendor IDEVID root-CA validation (and
returning which
vendors root-CA was used!).
So, before going any further into possible solution, i think we should try
to be clear
about what specific problem each of us wants to solve:
If i want to go through all the trouble of A), assigning muggle friendly
names first,
then i really wonder if we're promoting the best solution by first looking
into
.local solutions instead of trying to figure out what's missing so that i
can run
my own ACME certification on e.g.: my home (or private
industry/enterprise) network's
router for my own global domain. And how to get this all auto-configured
so that
muggles can operate it. I for once am not aware of any easily deployable
self-hosted
ACME server solution, and if whatever we come up with for .local would not
be a heck
of a lot easier than ACME, then we're not going to get that deployed
either in the
networks where we would like it.
In other words: I'd love to see good solutions for B), and i'd challenge
the priority
of A) (for .local) over solutions that do make global domain names more
easy to use in non-internet
use-cases. After all, it could be piece of cake to add my own networks
root-CA to
my browsers web-pki trust-anchor list if we wanted that to be the solution.
Cheers
toerless
On Wed, Aug 28, 2024 at 01:24:27AM +0000, Ben Schwartz wrote:
After the session we had a brief chat about this topic, and talked a bit
about the Matter/Thread ecosystem, which is an example of an ecosystem that
has attempted to solve the problem of bootstrapping trusted identities for
physically nearby network hardware. Notably, it does not appear to rely on
X.509 certificates for globally unique DNS names, like a typical TLS PKI.
I would be interested in whether the Matter/Thread device identity model
could be used to identify the CPE itself (which is often a "Thread border
router"), and whether that identity could be extended into web browsers
(for accessing the router management console) and the operating system (for
verifying the router's identity at the link layer, and potentially building
up verification from there to higher layer services like DNS).
--Ben
________________________________
From: Chris Box <[email protected]>
Sent: Saturday, August 24, 2024 10:25 AM
To: Dan Wing <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [Add] Re: Hosting Encrypted Servers on CPEs / HTTPS for Local
Domains
Hi everyone After a burst of discussion in Vancouver, this list has now
been silent for a month. My impression from the meeting is that we have a
widespread feeling that ADD isn't the correct venue for this problem. Ben
was quoted in the
Hi everyone
After a burst of discussion in Vancouver, this list has now been silent
for a month.
My impression from the meeting is that we have a widespread feeling that
ADD isn't the correct venue for this problem.
Ben was quoted in the minutes with:
I think the right answer here requires deeper
thought, and possibly going to the W3C and finding a new URI
scheme instead of "https" to represent local network
devices.
In an effort to try and move this along, I'll ask: where do you think
this should go?
Chris
On Wed, 24 Jul 2024 at 21:24, Dan Wing <[email protected]<mailto:
[email protected]>> wrote:
ADD WG,
While working to provide TLS for encrypted DNS on CPE, Tiru Reddy's
IETF119 ADD presentation made it clear ADD had bumped into a larger
problem: IETF and the industry has not documented how to best get
certificates onto CPE. A few companies (McAfee, Mozilla, Cujo) have
deployed a system where a unique FQDN is assigned to each CPE (e.g., to the
DNS server) and the CPE requests a vendor-operated cloud service to get
that certificate signed by a CA and returned to the CPE and CPE uses that
CA-signed certificate for incoming TLS connections. Such a system works
but the disadvantages are needing to get millions of certificates
continually signed by the CA (short-lived certificates) and continued
reliance on the vendor to operate the certificate-signing service.
Experience is that an exception is necessary to overcome the CA's normal
rate limit.
There are two documents that discuss such a system, its drawbacks, and
also explore some other system designs:
- Martin Thomson's "HTTPS for Local Domains" (*, below), and
- draft-rbw-add-encrypted-dns-forwarders (**, below).
Please read them prior to Thursday's ADD meeting, as I will only spend
3-4 minutes presenting and the rest of the time will be microphone
discussion.
I am hoping there are authors interested in writing a problem statement
document (if consensus is existing practice is too difficult) or writing a
BCP/Informational document on such a vendor-operated service (if consensus
is continue existing practice).
-d
(*) Martin Thomson's "HTTPS for Local Domains",
https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU/edit
<
https://urldefense.com/v3/__https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU/edit__;!!Bt8RZUm9aw!7NrFT-OD2YA0YvBly3H9PFhBLw2gdmCZmfBpntETQE0TJhHRYMFrMva9wtxbgyiZw6H1PiBRbeV8W2_JF3YS$>,
https://tinyurl.com/https-for-local-domains<
https://urldefense.com/v3/__https://tinyurl.com/https-for-local-domains__;!!Bt8RZUm9aw!7NrFT-OD2YA0YvBly3H9PFhBLw2gdmCZmfBpntETQE0TJhHRYMFrMva9wtxbgyiZw6H1PiBRbeV8W1lu4Aod$
(**) "Hosting Encrypted Servers on CPEs" slide deck for IETF120 ADD
meeting, https://datatracker.ietf.org/meeting/120/session/add<
https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/120/session/add__;!!Bt8RZUm9aw!7NrFT-OD2YA0YvBly3H9PFhBLw2gdmCZmfBpntETQE0TJhHRYMFrMva9wtxbgyiZw6H1PiBRbeV8WwG8mYuZ$
"Hosting Encrypted DNS Forwarders on CPEs",
https://datatracker.ietf.org/doc/draft-rbw-add-encrypted-dns-forwarders/<
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-rbw-add-encrypted-dns-forwarders/__;!!Bt8RZUm9aw!7NrFT-OD2YA0YvBly3H9PFhBLw2gdmCZmfBpntETQE0TJhHRYMFrMva9wtxbgyiZw6H1PiBRbeV8WypLQL9h$
--
---
[email protected]
--
Add mailing list -- [email protected]
To unsubscribe send an email to [email protected]
