[Anima] Re: [Add] Hosting Encrypted Servers on CPEs / HTTPS for Local Domains

[Dan Wing <[e-mail]>]

On Sep 10, 2024, at 10:01 AM, Toerless Eckert <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> Sent: Saturday, August 24, 2024 10:25 AM
>>>> To: Dan Wing <[e-mail]>
>>>> Cc: [e-mail] <[e-mail]>
>>>> 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 <[e-mail]<mailto:
>>> [e-mail]>> 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$
>>>> 
>>>> 
>>> 
>>> --
>>> ---
>>> [e-mail]
>>> 
>>> --
>>> Add mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>> 
> 
> -- 
> ---
> [e-mail]