I think that the non-muggle-friendly-names may be a core problem to solve
first for many of these use-cases.
For example, ADD doesn't need its names to be muggle-friendly.
There may be ways to layer things to wrap a better user experience on top.
For example, providing a way for a user to locally associate a
human-friendly bookmark
for an underlying endpoint identity.
I wonder if this would make sense to start as a BOF (or even a workshop) of
its own, first focused on use-cases
and exploring the space? It may be too early to jump into the "should this
get a new URL scheme".
It might help to try and factor up the various pieces here, many of which
are interrelated.
For example:
* Having endpoints names (eg, the Web Origin) include a public
cryptographic identity
* How to represent this in URIs at a protocol layer
* How to handle important corner cases (crypto agility, multiple
algorithms, key rotations, etc)
* If a trust web is needed, how to establish it and represent it
* How to expose the endpoint identities, URIs, etc to human users in a way
that provides a good user experience
* How this relates to W3C concepts (eg, "secure origins") and user-agent
experience (eg, the "lock icon" and URL bar and such)
* The user experience for any trust hierarchy establishment.
If a trust web is needed, it would be nice to be able to plug into models
like Matter/Thread,
but I think a key aspect is that we want to avoid any need for a global
hierarchical trust system.
The pieces here are going to be cross-domain, so success likely will
require bringing
a few different communities together, but also keeping scope bounded enough
to keep
complexity under control.
Erik
On Thu, Sep 5, 2024 at 8:02 PM Toerless Eckert <[email protected]> wrote:
> 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]
>
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
