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

[Lanlan Pan <[e-mail]>]

Using Matter identity model:
1) CPE acts as commissionee device:
The commissionee device (CPE) should make spake2+ pairing with commissioner
device (such as mobile phone),   send its device attestation to
commissioner device, finally get its certificate from commissioner device.
CPE certificate is provided by commissioner device (such as mobile phone),
not a typical TLS certificate with domain names.
CPE certificate can identify the CPE itself  to other commissionee devices,
because they are all pairing with commissioner device, following the same
self-signed root certificate trust chain.

2) Alternatively,  CPE acts as commissioner device:
CPE provides its self-signed root certificate trust chain.
Each commissionee device make wi-fi connection with CPE,  gets CPE's
self-signed root certificate trust chain.
Commissionee device doesn't have its own certificate, but only get CPE's
certificate.
CPE certificate can identify the CPE itself to the commissionee devices,
use some *.local domain name as the TLS certificate subject name.


Commissionee device store the CPE certificate self-signed root certificate
trust chain:
1)  write into local system trusted root ca store
If write into local system trusted root ca, it could extend into web
browsers and the operating system.
But write a self-signed root into local system trusted root ca store will
increase the TLS hijack risk.

2)  Alternatively, write into a specific root certificate store only for
local visit
The specific root certificate store path  should be assigned to a
well-known path, and only for local visit use.
Stub resolver/browser should extend to read the specific root certificate
store, and visit local website (DoH, or the router management console)
follow the chain.


I think this is more secure:  CPE acts as commissioner device, and
commissionee device write the CPE certificate self-signed root certificate
into a specific root certificate store only for local visit.

Best Regards,
潘蓝兰(Pan Lanlan)

Ben Schwartz <bemasc=[e-mail]> 于2024年8月28日周三 09:24写道：

> 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]> 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$>
>
> --
> Add mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>