On Sep 10, 2024, at 10:01 AM, Toerless Eckert <[email protected]> wrote: > > 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.
As suggested in (*), a device with a long name can also advertise a short name (e.g., mDNS), allowing the user to visit "https://router.local"; (or "https://printer.local"; or "https://printer.home.example.net";, which is a CNAME to the long name. The client, encountering the long name, can then initiate the its bootstrapping to trusting (*) the long name ("https://router.ejfkejfkejfejkejfkjkej.local";), or if bootstrapping has already occurred the client would immediately see the router's (or printer's) HTTPS configuration page. The long names are not a severe problem. (*) Martin Thomson's "HTTPS for Local Domains" (https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU) (**) QR, type magic codes, TOFU, NFC, etc. > 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... ? Could you detail why that is necessary? -d >> 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]
