From: Dan Wing <danwing@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2F8E2A4B-AEE3-4149-85EB-6E079760D493"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Message-Id: <6FCA933A-F329-4B45-9C72-32FFCAD289BE@gmail.com>
Date: Wed, 24 Jul 2024 13:22:22 -0700
To: add@ietf.org
Message-ID-Hash: 672Q6C4POIFE7MWRIPL67OZASQTSU4MI
Precedence: list
Subject: =?utf-8?q?=5BAdd=5D_Hosting_Encrypted_Servers_on_CPEs_/_HTTPS_for_Local_Doma?=
	=?utf-8?q?ins?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/add/-aK8R2X1QAHiwq6A4-Jy80c6Bdc>


--Apple-Mail=_2F8E2A4B-AEE3-4149-85EB-6E079760D493
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQX=
YPmzU/edit, https://tinyurl.com/https-for-local-domains

(**) "Hosting Encrypted Servers on CPEs" slide deck for IETF120 ADD =
meeting, https://datatracker.ietf.org/meeting/120/session/add
      "Hosting Encrypted DNS Forwarders on CPEs", =
https://datatracker.ietf.org/doc/draft-rbw-add-encrypted-dns-forwarders/


--Apple-Mail=_2F8E2A4B-AEE3-4149-85EB-6E079760D493
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div>ADD =
WG,</div><div><br></div><div>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. &nbsp;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. &nbsp;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. &nbsp;Experience is that an =
exception is necessary to overcome the CA's normal rate =
limit.</div><div><br></div><div>There are two documents that discuss =
such a system, its drawbacks, and also explore some other system =
designs:</div><div>&nbsp; - Martin Thomson's "HTTPS for Local Domains" =
(*, below), and</div><div>&nbsp; - =
draft-rbw-add-encrypted-dns-forwarders (**, =
below).</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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).</div><div><br></div><div>-d</div><div><br></div><div><br></div>=
<div>(*) Martin Thomson's "HTTPS for Local Domains",&nbsp;<a =
href=3D"https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQ=
XzfikBQXYPmzU/edit">https://docs.google.com/document/d/170rFC91jqvpFrKIqG4=
K8Vox8AL4LeQXzfikBQXYPmzU/edit</a>,&nbsp;<a =
href=3D"https://tinyurl.com/https-for-local-domains" style=3D"font-family:=
 =
Arial;">https://tinyurl.com/https-for-local-domains</a></div><div><br></di=
v>(**) "Hosting Encrypted Servers on CPEs" slide deck for IETF120 ADD =
meeting,&nbsp;<a =
href=3D"https://datatracker.ietf.org/meeting/120/session/add">https://data=
tracker.ietf.org/meeting/120/session/add</a><div>&nbsp; &nbsp; &nbsp; =
"Hosting Encrypted DNS Forwarders on CPEs",&nbsp;<a =
href=3D"https://datatracker.ietf.org/doc/draft-rbw-add-encrypted-dns-forwa=
rders/">https://datatracker.ietf.org/doc/draft-rbw-add-encrypted-dns-forwa=
rders/</a></div><div><br></div></body></html>=

--Apple-Mail=_2F8E2A4B-AEE3-4149-85EB-6E079760D493--