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

[Toerless Eckert <[e-mail]>]

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]