Subject: [Add] Discovery of Equivalent Encrypted Resolvers

From: Tommy Pauly <[email-masked]>
Date: Tue, 03 Nov 2020 08:34:14 -0800

Hello ADD,

A few of us have written up a simplified description of the mechanism to use DNS records to discover encrypted DNS servers, focusing on the clearest cases discussed in the previous interim (bootstrapping from an unencrypted resolver, etc).

https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html <https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html>

Your comments and thoughts are welcome and appreciated!

Best,
Tommy

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Nov 2020 12:35:17 -0500

Thanks for this draft.  I support this approach, and I think the clear
distinction between named, IP-authenticated, and opportunistic modes is
very helpful.

Some notes:

A. Security design
> "In order to be considered an authenticated Equivalent Encrypted
Resolver, the TLS certificate presented by the Encrypted Resolver MUST
contain both the domain name (from the SVCB answer) and the IP address of
its equivalent Unencrypted Resolver"

Requiring the certificate to cover the TargetName is unusual.  Why does it
help for the certificate to contain this domain name, if it is also
required to authenticate or match the DNS server IP?  Is a nontrivial
TargetName always required?

> "An attacker might try to direct Encrypted DNS traffic to itself by
causing the client to think that a discovered Equivalent Encrypted Resolver
uses a different IP address from the Unencrypted Resolver."

It seems like you are contemplating an attacker who controls the DNS path
but not the RA/DHCP path.  I'd appreciate seeing a few more words on that
beyond the current reference to RA protection.

In general, some text on threat modeling might help to justify the design
decisions.

B. Interaction with other options
I would appreciate a sentence on how the opportunistic mode interacts with
"probe port 853 for DoT".

C. Hints
> "These address hints ... avoid additional DNS lookup for the A and AAAA
records of the Encrypted Resolver name."

Strictly speaking, a compliant SVCB client is expected to perform the
additional lookups anyway.  The hints just avoid a delay while those
queries complete.  If you think it's important to "skip" those followup
queries, we would have to make a deeper change.  Otherwise, you could say
"avoid *waiting for* DNS lookup...".

On Tue, Nov 3, 2020 at 11:34 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello ADD,
>
> A few of us have written up a simplified description of the mechanism to
> use DNS records to discover encrypted DNS servers, focusing on the clearest
> cases discussed in the previous interim (bootstrapping from an unencrypted
> resolver, etc).
>
> https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 04 Nov 2020 12:49:28 -0800

Thanks for the review, Ben! Responses inline.

> On Nov 3, 2020, at 9:35 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> Thanks for this draft.  I support this approach, and I think the clear distinction between named, IP-authenticated, and opportunistic modes is very helpful.
> 
> Some notes:
> 
> A. Security design
> > "In order to be considered an authenticated Equivalent Encrypted Resolver, the TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of its equivalent Unencrypted Resolver"
> 
> Requiring the certificate to cover the TargetName is unusual.  Why does it help for the certificate to contain this domain name, if it is also required to authenticate or match the DNS server IP?  Is a nontrivial TargetName always required?
> 
> > "An attacker might try to direct Encrypted DNS traffic to itself by causing the client to think that a discovered Equivalent Encrypted Resolver uses a different IP address from the Unencrypted Resolver."
> 
> It seems like you are contemplating an attacker who controls the DNS path but not the RA/DHCP path.  I'd appreciate seeing a few more words on that beyond the current reference to RA protection.
> 
> In general, some text on threat modeling might help to justify the design decisions.

Partly, I’m imagining we can rely on or take some of the threat modeling text from the requirements document here. However, I agree that that should be referenced or included.

https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/143 <https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/143>

> I would appreciate a sentence on how the opportunistic mode interacts with "probe port 853 for DoT".

Good point! We can add text for that. I think if you have an SVCB record indicating a DoT (or DoH) server, that supplants needing to probe port 853, but they are essentially equivalent.

https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/144 <https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/144>

> 
> C. Hints
> > "These address hints ... avoid additional DNS lookup for the A and AAAA records of the Encrypted Resolver name."
> 
> Strictly speaking, a compliant SVCB client is expected to perform the additional lookups anyway.  The hints just avoid a delay while those queries complete.  If you think it's important to "skip" those followup queries, we would have to make a deeper change.  Otherwise, you could say "avoid *waiting for* DNS lookup...".

Yes, I think it would be better to just “avoid waiting for” here.

https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/145 <https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/145>

Best,
Tommy
> 
> On Tue, Nov 3, 2020 at 11:34 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> Hello ADD,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Nov 2020 12:34:20 +1100

On Thu, Nov 5, 2020, at 07:49, Tommy Pauly wrote:
> Partly, I’m imagining we can rely on or take some of the threat 
> modeling text from the requirements document here. However, I agree 
> that that should be referenced or included.
> 
> https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/143

(Also posted on the issue.)

I think that for equivalence, it is sufficient to include just the ipAddress SAN. Clients have to have a single target identity to match, or it gets a little tricky.

This assumes that the provenance of the IP is somehow not subject to attack. This includes DHCP/RA, manual configuration, and other forms of configuration like enterprise policy systems.

But it's not really that. This isn't about establishing whether the IP address is the right one, it's about saying affirmatively that this is the same as this other thing. For that, you don't need to worry about where the IP address came from. Of course, this is a stronger assertion regarding the DoT/DoH server than you can make about the Do53 server. The former is authenticated; the latter relies on the integrity of the route.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 5 Nov 2020 14:59:28 +0100

On Tue, Nov 03, 2020 at 08:34:14AM -0800,
 Tommy Pauly <tpauly=[email-masked]> wrote 
 a message of 47 lines which said:

> A few of us have written up a simplified description of the
> mechanism to use DNS records to discover encrypted DNS servers,
> focusing on the clearest cases discussed in the previous interim
> (bootstrapping from an unencrypted resolver, etc).
> 

I like the name and specially the fact that this name says clearly that the
encrypted resolver is not "better" (more trustable) than the
unencrypted one. This is reasonable.

> The client MUST check the SubjectAlternativeName field for both the
> Unencrypted Resolver's IP address

How do you think we can address the case of unencrypted resolvers on
RFC 1918 addresses? Should this practice be discouraged?

> Resolver owners that support authenticated discovery will need to
> list valid referring IP addresses in their TLS certificates.  This
> may pose challenges for resolvers with a large number of referring
> IP addresses.

And also with the many CA that do not accept to put IP addresses in
certificates (the most important one being Let's Encrypt).

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 05 Nov 2020 08:12:24 -0800

> On Nov 5, 2020, at 5:59 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

If your unencrypted resolver is on a private address, you essentially have two options:

1. Host your equivalent encrypted resolver on the same IP address, which puts us in the “opportunistic” bucket defined in the draft. This isn’t strongly authenticated, but it works and still lets you discover the right path for DoH, etc.
2. Provision the name of the encrypted resolver via DHCP/RA, which means we don’t need to worry about IP addresses matching.

The case for having IP addresses be in certs is for cases where the IP address is public and can be in a cert—i.e., I could send the resolver.arpa query to 1.1.1.1 and learn about it’s DoT and DoH capabilities.

> certificates (the most important one being Let's Encrypt).

Indeed. However, this is possible and already done for some resolvers with public IP addresses, so it is still a useful mechanism for those cases.

Best,
Tommy

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Nov 2020 01:25:44 +0000

> https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html

Re. section 4, queries for _dns.resolver.arpa:

A neat way to support this would be if the resolver could reply with

_dns.resolver.arpa. CNAME _dns.resolvers-own-hostname

At least some resolvers know their own hostnames, so they could have a
built-in default resolver.arpa zone, allowing the resolver admin to
provision the SVCB records under the real resolver hostname(s) without
also having to explicitly set up the special-use name.

So section 8.1 is correct to say that resolver.arpa needs to be the
special zone name, so that _dns.resolver.arpa can be a CNAME.

[ related but off-topic, I'm eagerly looking for RFC 8738 support at
atttps://letsencrypt.org/upcoming-features/ ]

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
The Minch: South or southwest 5 to 7, decreasing 3 to 5. Slight or moderate,
but rough near northern and southern entrances. Occasional drizzle. Moderate
or good, occasionally poor.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 06 Nov 2020 08:26:22 -0800

Yes, a CNAME could be used. Note that SVCB also allows the name to be provided in the answer. So, the answer could be:

_dns.resolver.arpa  7200  IN SVCB 1 resolver-hostname.net (
     alpn=dot ipv4hint=x.y.z.w )

Thanks,
Tommy

> On Nov 5, 2020, at 5:25 PM, Tony Finch <[email-masked]> wrote:
>

---

From: Chris Box <[email-masked]>
Date: Wed, 11 Nov 2020 18:36:24 +0000

On Thu, 5 Nov 2020 at 16:12, Tommy Pauly <tpauly=[email-masked]>
wrote:

> 1. Host your equivalent encrypted resolver on the same IP address, which
> puts us in the “opportunistic” bucket defined in the draft. This isn’t
> strongly authenticated, but it works and still lets you discover the right
> path for DoH, etc.
> 2. Provision the name of the encrypted resolver via DHCP/RA, which means
> we don’t need to worry about IP addresses matching.
>

Tommy,

For option 1, consider a case where a home CPE isn't able, or isn't
considered secure enough, to run a TLS server. Would it be acceptable for
this CPE to operate a simple TCP proxy to a more distant equivalent
encrypted resolver, so that 192.168.0.1:853 is proxied at TCP level to
<public IP>:853? At first glance this would seem to meet your opportunistic
validation requirement.

But option 2, such as that enabled by draft-btw-add-home-10, appears to be
better.

Chris

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 11 Nov 2020 17:03:52 -0800

> On Nov 11, 2020, at 10:36 AM, Chris Box <[email-masked]> wrote:
> 
> On Thu, 5 Nov 2020 at 16:12, Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> 
> For option 1, consider a case where a home CPE isn't able, or isn't considered secure enough, to run a TLS server. Would it be acceptable for this CPE to operate a simple TCP proxy to a more distant equivalent encrypted resolver, so that 192.168.0.1:853 <http://192.168.0.1:853/> is proxied at TCP level to <public IP>:853? At first glance this would seem to meet your opportunistic validation requirement.

Yes, I think that would meet the bar for opportunistic. Effectively, we would have confirmation that the local resolver (or whoever controls the local resolver’s IP address) is handling the traffic, even if it is just forwarded. This is definitely better than just pointing the client to an entirely different IP address.
> 
> But option 2, such as that enabled by draft-btw-add-home-10, appears to be better.

Agreed.

Best,
Tommy