Subject: [Add] CAA recommendation (DEER)

From: JW λ John Woodworth <[email-masked]>
Date: Mon, 16 Nov 2020 18:54:15 -0500

Hello,While reading the DEER draft, I had the thought that it may be a good idea to make use of CAA records a recommendation for encrypted-DNS certificates.  I can see potential issues with open CA issued certificates.Thanks, John

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 17 Nov 2020 06:01:56 +0000

Hey John,

I'm not sure how CAA records would help in the primary scenario of DEER where the stub is configured only with an IP address. Can you elaborate?

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of JW λ John Woodworth <[email-masked]>
Sent: Monday, November 16, 2020 3:54 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [EXTERNAL] [Add] CAA recommendation (DEER)

Hello,

While reading the DEER draft, I had the thought that it may be a good idea to make use of CAA records a recommendation for encrypted-DNS certificates.  I can see potential issues with open CA issued certificates.

Thanks,
John

---

From: JW λ John Woodworth <[email-masked]>
Date: Tue, 17 Nov 2020 13:15:15 -0500

Hi Tommy, Apologies for my vagueness.One of my objectives is to move some of the DNS decision making back to the CPE.  We have some influence over our vendors regarding features.Today, the CPE has knowledge of both parts of a split-horizon DNS and I would like to leverage this knowledge via an encrypted-DNS enabled proxy on supported CPE's.This means _potentially_ managing millions of certificates and hostnames,  unique rfc1918 addresses, etc.  I'm thinking in this scenario we'd want to tread carefully regarding which CA wins in a tie, should bad things happen.I realize this may be a corner case but felt it worth sharing.Thanks, John
-------- Original message --------From: Tommy Jensen <Jensen.Thomas=[email-masked]>

Hey John,

Thanks,

Tommy

Hello,

Thanks, 
John

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 18 Nov 2020 14:33:40 +1100

I think that the DHCP/RA options for discovery provide that path.  If you can advertise DoT/DoH that way, then the clients might well decide there is no need to use DEER on that network.

On Wed, Nov 18, 2020, at 05:15, JW λ John Woodworth wrote:
> Hi Tommy, 
> 
> Apologies for my vagueness.
> 
> One of my objectives is to move some of the DNS decision making back to 
> the CPE.  We have some influence over our vendors regarding features.
> 
> Today, the CPE has knowledge of both parts of a split-horizon DNS and I 
> would like to leverage this knowledge via an encrypted-DNS enabled 
> proxy on supported CPE's.
> 
> This means _potentially_ managing millions of certificates and 
> hostnames,  unique rfc1918 addresses, etc.  I'm thinking in this 
> scenario we'd want to tread carefully regarding which CA wins in a tie, 
> should bad things happen.
> 
> I realize this may be a corner case but felt it worth sharing.
> 
> Thanks, 
> John
> 
> -------- Original message --------
> From: Tommy Jensen <Jensen.Thomas=[email-masked]>
> 
> Hey John,
> 
> I'm not sure how CAA records would help in the primary scenario of DEER 
> where the stub is configured only with an IP address. Can you elaborate?
> 
> Thanks,
> Tommy
> 
> *From:* Add <[email-masked]> on behalf of JW λ John Woodworth 
> <[email-masked]>
> *Sent:* Monday, November 16, 2020 3:54 PM
> *To:* [email-masked] <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* [EXTERNAL] [Add] CAA recommendation (DEER) 
>  
> Hello,
> 
> While reading the DEER draft, I had the thought that it may be a good 
> idea to make use of CAA records a recommendation for encrypted-DNS 
> certificates.  I can see potential issues with open CA issued 
> certificates.
> 
> 
> Thanks, 
> John
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 18 Nov 2020 11:05:44 +0700

Hi John,

You may want to look into https://tools.ietf.org/html/draft-btw-add-home-10,
it discusses DHCP/RA extensions to discover the network-provided encrypted
forwarder hosted on the CPE or network-provided encrypted resolver hosted
in the ISP cloud.

Resolver-identified discovery (DEER) can be used as a fallback for legacy
(or non-upgradable) CPE.

The draft also discusses that a ISP can assign a unique FQDN (e.g.,
cpe1.example.com) and a
domain-validated public certificate to the encrypted DNS forwarder hosted
on the managed CPE.  Automatic Certificate Management Environment (ACME)
can be used by the ISP to automate certificate management functions such as
domain validation procedure, certificate
issuance and certificate revocation.

The other possible approach without having to manage public certificates on
the home router is delegated credentials for TLS (see
https://tools.ietf.org/html/draft-ietf-tls-subcerts-09) with keyless as a
fallback.

Cheers,
-Tiru

On Wed, 18 Nov 2020 at 01:15, JW λ John Woodworth <[email-masked]> wrote:

> would like to leverage this knowledge via an encrypted-DNS enabled proxy on
> supported CPE's.
>
> This means _potentially_ managing millions of certificates and hostnames,
> unique rfc1918 addresses, etc.  I'm thinking in this scenario we'd want to
> tread carefully regarding which CA wins in a tie, should bad things happen.
>
> ------------------------------
> *From:* Add <[email-masked]> on behalf of JW λ John Woodworth <
> [email-masked]>
> While reading the DEER draft, I had the thought that it may be a good idea
> to make use of CAA records a recommendation for encrypted-DNS
> certificates.  I can see potential issues with open CA issued certificates.
>
>
> Thanks,
> John
>
> --
> Add mailing list
> [email-masked]

---

From: JW λ John Woodworth <[email-masked]>
Date: Wed, 18 Nov 2020 02:10:44 -0500

Hi Martin,Thank you!  I will dig into this more./John 
-------- Original message --------From: Martin Thomson <[email-masked]>I think that the DHCP/RA options for discovery provide that path.  If you can advertise DoT/DoH that way, then the clients might well decide there is no need to use DEER on that network.On Wed, Nov 18, 2020, at 05:15, JW λ John Woodworth wrote:> Hi Tommy, > > Apologies for my vagueness.> > One of my objectives is to move some of the DNS decision making back to > the CPE.  We have some influence over our vendors regarding features.> > Today, the CPE has knowledge of both parts of a split-horizon DNS and I > would like to leverage this knowledge via an encrypted-DNS enabled > proxy on supported CPE's.> > This means _potentially_ managing millions of certificates and > hostnames,  unique rfc1918 addresses, etc.  I'm thinking in this > scenario we'd want to tread carefully regarding which CA wins in a tie, > should bad things happen.> > I realize this may be a corner case but felt it worth sharing.> > Thanks, > John> > -------- Original message --------> From: Tommy Jensen <Jensen.Thomas=[email-masked]>> > Hey John,> > I'm not sure how CAA records would help in the primary scenario of DEER > where the stub is configured only with an IP address. Can you elaborate?> > Thanks,> Tommy> > *From:* Add <[email-masked]> on behalf of JW λ John Woodworth > <[email-masked]>> *Sent:* Monday, November 16, 2020 3:54 PM> *To:* [email-masked] <[email-masked]>> *Cc:* [email-masked] <[email-masked]>> *Subject:* [EXTERNAL] [Add] CAA recommendation (DEER) >  > Hello,> > While reading the DEER draft, I had the thought that it may be a good > idea to make use of CAA records a recommendation for encrypted-DNS > certificates.  I can see potential issues with open CA issued > certificates.> > > Thanks, > John> > -- > Add mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/add>-- Add mailing [email-masked]://www.ietf.org/mailman/listinfo/add

---

From: JW λ John Woodworth <[email-masked]>
Date: Wed, 18 Nov 2020 02:13:35 -0500

Hi Tiru,Thank you for the links!  I will review and see if this solves things for me./John 
-------- Original message --------From: tirumal reddy <[email-masked]>Hi John,You may want to look into https://tools.ietf.org/html/draft-btw-add-home-10, it discusses DHCP/RA extensions to discover the network-provided encrypted forwarder hosted on the CPE or network-provided encrypted resolver hosted in the ISP cloud. Resolver-identified discovery (DEER) can be used as a fallback for legacy (or non-upgradable) CPE.The draft also discusses that a ISP can assign a unique FQDN (e.g., cpe1.example.com) and adomain-validated public certificate to the encrypted DNS forwarder hosted on the managed CPE.  Automatic Certificate Management Environment (ACME) can be used by the ISP to automate certificate management functions such as domain validation procedure, certificateissuance and certificate revocation.The other possible approach without having to manage public certificates on the home router is delegated credentials for TLS (see https://tools.ietf.org/html/draft-ietf-tls-subcerts-09) with keyless as a fallback.Cheers,-TiruOn Wed, 18 Nov 2020 at 01:15, JW λ John Woodworth <[email-masked]> wrote:Hi Tommy, Apologies for my vagueness.One of my objectives is to move some of the DNS decision making back to the CPE.  We have some influence over our vendors regarding features.Today, the CPE has knowledge of both parts of a split-horizon DNS and I would like to leverage this knowledge via an encrypted-DNS enabled proxy on supported CPE's.This means _potentially_ managing millions of certificates and hostnames,  unique rfc1918 addresses, etc.  I'm thinking in this scenario we'd want to tread carefully regarding which CA wins in a tie, should bad things happen.I realize this may be a corner case but felt it worth sharing.Thanks, John-------- Original message --------From: Tommy Jensen <Jensen.Thomas=[email-masked]>

Hey John,

Thanks,

Tommy

Hello,

Thanks, 
John