On Fri, Sep 06, 2024 at 10:38:12PM -0400, Erik Nygren wrote:
> 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.
Great to know!
There actually seem to be a lot of DNS names these days that are not appropriate
for muggles (and hence arguably not for entering into browser URL bar). Alas,
we still have normative documents such as RFC6763 that do a great job in
outlining
all the aspects to make URLs muggle friendly - but no updates to explain that
the
scope of our solution deployments has expanded beyond that (which IMHO is
primarily
an issue re. our discuss with W3C as explained in my other reply in this
thread).
> 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.
Why ask to use some non-defined magical system such as "bookmarks" when we
could instead
simply ask to push CNAMEs into DNS. Thats something we can define. Makes me just
wonder if we have a standard practice way for reverse resolution - if i have
the serial-number domain name -> how would i find all the CNAMEs for it... ?
> 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".
Maybe just starting to write / collect the different aspects of this problem.
Such as some other (like martin thomson) have done from their side. ...
> 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)
I'd hope this point would hopefully be separate from anything URL, or else
we'd have to chew way too much.
> * If a trust web is needed, how to establish it and represent it
I think it would be lovely if we would find some DNS anchored registry for
IDEVID CA certificates so that it would become easy for arbitrary 3rd party
vendors to build IOT controller applications that could validate IDEVID
certificates for any type of bootstrap workflows. Might be possible to expand
into LDEVID space as well...
> * How to expose the endpoint identities, URIs, etc to human users in a way
> that provides a good user experience
I think you always need some process for binding a user-friendly names.
RFC6763 has some good suggestions for useful vendor defaults though. And
if we go through DNS with above inquired reverse resolution, one might even
automate default name disambiguation (aka "Vendor Type Printer #22" - where
#22 is generated by figuring that #1..#21 already exist in the local domain).
> * How this relates to W3C concepts (eg, "secure origins") and user-agent
> experience (eg, the "lock icon" and URL bar and such)
Right.
> * 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.
Maybe turn it around and wonder if/what type of delegation of trust may need
to be supported.
Cheers
Toerless
> 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]
> >
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
