Subject: [Add] I-D Action: draft-ietf-add-ddr-01.txt

From: [email-masked]
Date: Mon, 14 Jun 2021 15:59:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Adaptive DNS Discovery WG of the IETF.

        Title           : Discovery of Designated Resolvers
        Authors         : Tommy Pauly
                          Eric Kinnear
                          Christopher A. Wood
                          Patrick McManus
                          Tommy Jensen
	Filename        : draft-ietf-add-ddr-01.txt
	Pages           : 12
	Date            : 2021-06-14

Abstract:
   This document defines Discovery of Designated Resolvers (DDR), a
   mechanism for DNS clients to use DNS records to discover a resolver's
   encrypted DNS configuration.  This mechanism can be used to move from
   unencrypted DNS to encrypted DNS when only the IP address of an
   encrypted resolver is known.  It can also be used to discover support
   for encrypted DNS protocols when the name of an encrypted resolver is
   known.  This mechanism is designed to be limited to cases where
   unencrypted resolvers and their designated resolvers are operated by
   the same entity or cooperating entities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-add-ddr/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-add-ddr-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-add-ddr-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tommy Jensen <[email-masked]>
Date: Mon, 14 Jun 2021 23:04:16 +0000

Hey everyone,

We have posted an update to DDR and welcome additional review. Many thanks to everyone who has reviewed so far. We are hoping to get additional feedback as we rev a -02 ahead of the deadline for IETF 111.

This version addresses some feedback regarding the use of IPv4/IPv6 examples, the use of IP hints, and some clarity of language regarding terminology ("equivalence" versus "designation") and scope.

I would like to highlight for the benefit of some feedback regarding scope that the scope of this draft remains limited in nature. For example, DDR has not and still does not attempt to solve the "85%" problem. You will see commentary on the GitHub bugs following that scoping.

Thanks,
Tommy

> -----Original Message-----
> From: Add <[email-masked]> On Behalf Of [email-masked]
> Sent: Monday, June 14, 2021 3:59 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [EXTERNAL] [Add] I-D Action: draft-ietf-add-ddr-01.txt
> 
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fdoc%2Fdraft-ietf-add-
> ddr%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C4efbe3
> 5963a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=aSaQVCpy5v%2B%2BrQY%2FO%2B58%2FpsuYInrrSFnFOSnIQQPeRw
> %3D&amp;reserved=0
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-add-ddr-
> 01.html&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C4efbe3
> 5963a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=zv0FOkEWCo9PbEcvzc%2FcjuZTWAi53Td6dsOuY5hKyEs%3D&amp;re
> served=0
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-add-ddr-
> 01&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C4efbe35963
> a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
> data=QgeVUjM%2F5bSTseBkg0tytJ3RT0ztD56xoYmK4pKfJ%2Fs%3D&amp;reser
> ved=0
> 
> 
> https://nam06.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.or
> g%2Finternet-
> drafts%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C4efb
> e35963a949fea69f08d92f8810a7%7C72f988bf86f141af91ab2d7cd011db47%7
> C1%7C0%7C637593083738862826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> &amp;sdata=%2Fc8xtaTsW%2BmcWpqCR6oHJkY6hyN%2B3K02Ae6%2BRpCfLN
> w%3D&amp;reserved=0
> 
> 
> --
> Add mailing list
> [email-masked]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas
> %40microsoft.com%7C4efbe35963a949fea69f08d92f8810a7%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637593083738862826%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C1000&amp;sdata=Z71SomUyHBgCR8RoMIfGzH7bcURYM
> 7CNUr2JfSvG%2BM0%3D&amp;reserved=0

---

From: Chris Box <[email-masked]>
Date: Tue, 15 Jun 2021 18:25:22 +0100

Tommy,

It's a good set of improvements over the wording in -00. Thumbs up on those.

I certainly appreciate DDR (even with DNR added) doesn't entirely solve the
85% problem; Barbara and I have written up some thoughts on that which
she'll be sharing to the list imminently.

Which Github bugs/issues were you referring to?

Chris

On Tue, 15 Jun 2021 at 00:05, Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> Hey everyone,
>
> We have posted an update to DDR and welcome additional review. Many thanks
> to everyone who has reviewed so far. We are hoping to get additional
> feedback as we rev a -02 ahead of the deadline for IETF 111.
>
> This version addresses some feedback regarding the use of IPv4/IPv6
> examples, the use of IP hints, and some clarity of language regarding
> terminology ("equivalence" versus "designation") and scope.
>
> I would like to highlight for the benefit of some feedback regarding scope
> that the scope of this draft remains limited in nature. For example, DDR
> has not and still does not attempt to solve the "85%" problem. You will see
> commentary on the GitHub bugs following that scoping.
>
> Thanks,
> Tommy
>
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 16 Jun 2021 11:10:40 -0400

Thanks for the update.  On the "85%" topic, I've rebased my PR  to the
latest draft: https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/11.

On Tue, Jun 15, 2021 at 1:25 PM Chris Box <[email-masked]> wrote:

> I certainly appreciate DDR (even with DNR added) doesn't entirely solve
> the 85% problem; Barbara and I have written up some thoughts on that which
>> We have posted an update to DDR and welcome additional review. Many
>> thanks to everyone who has reviewed so far. We are hoping to get additional
>> I would like to highlight for the benefit of some feedback regarding
>> scope that the scope of this draft remains limited in nature. For example,
>> DDR has not and still does not attempt to solve the "85%" problem. You will
>> see commentary on the GitHub bugs following that scoping.
>>
>> Thanks,
>> Tommy
>>

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 16 Jun 2021 15:47:39 +0000

Hey Chris: apparently only ones we have already closed on checking. You can ignore what I said.

Hey Ben,

I appreciate your efforts in keeping up with the base draft, but I think your proposal is best served by a separate document. The expanded scope it introduces significantly lowers the security posture of DDR overall, which you indirectly acknowledge in the text:

“If the client does not have a Validation Identity, or the Validation Identity
was discovered insecurely (e.g. via CNAME), the client SHOULD limit the
validity duration of the discovered information (e.g. the SVCB response
TTL) to no more than 5 minutes. The client MAY make use of this encrypted
connection, but SHOULD NOT assume that the connection is more secure
than an unencrypted connection.”

I do not think we should be trying to add this to a standard that otherwise provides connections of improved security. While DDR can be blocked by an on-path attacker, a successful upgrade can be trusted to be an entity designated by the original resolver owner. This PR introduces a mechanism where that is not true.

Since clients will have different opinions on the need to support DDR as it is currently defines versus this PR, we should provide them as separate documents to avoid clients deploying only partial standard support (as it seems likely many will choose to not support this option).

Thanks,
Tommy

From: Ben Schwartz <bemasc=[email-masked]>
Sent: Wednesday, June 16, 2021 8:11 AM
To: Chris Box <[email-masked]>
Cc: Tommy Jensen <[email-masked]>; [email-masked]
Subject: Re: [Add] [EXTERNAL] I-D Action: draft-ietf-add-ddr-01.txt

Thanks for the update.  On the "85%" topic, I've rebased my PR  to the latest draft: https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/11.

On Tue, Jun 15, 2021 at 1:25 PM Chris Box <[email-masked]<mailto:[email-masked]>> wrote:
Tommy,

I certainly appreciate DDR (even with DNR added) doesn't entirely solve the 85% problem; Barbara and I have written up some thoughts on that which she'll be sharing to the list imminently.

Chris

On Tue, 15 Jun 2021 at 00:05, Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrote:
Hey everyone,

Thanks,
Tommy

> From: Add <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> cker.ietf.org<http://cker.ietf.org>%2Fdoc%2Fdraft-ietf-add-
> ddr%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efbe3
> tf.org<http://tf.org>%2Farchive%2Fid%2Fdraft-ietf-add-ddr-
> 01.html&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efbe3
> tf.org<http://tf.org>%2Frfcdiff%3Furl2%3Ddraft-ietf-add-ddr-
> 01&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efbe35963
> drafts%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com<http://40microsoft.com>%7C4efb
> [email-masked]<mailto:[email-masked]>
> tf.org<http://tf.org>%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas
> %40microsoft.com<http://40microsoft.com>%7C4efbe35963a949fea69f08d92f8810a7%7C72f988bf86f1

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 16 Jun 2021 12:35:38 -0400

On Wed, Jun 16, 2021 at 11:47 AM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:
...

> Hey Ben,
>
>
>
> I appreciate your efforts in keeping up with the base draft, but I think
> your proposal is best served by a separate document.
>

Perhaps.  I think we need more WG input on which use cases are most
relevant.

The expanded scope it introduces significantly lowers the security posture
> of DDR overall, which you indirectly acknowledge in the text:
>
>
>
> I do not think we should be trying to add this to a standard that
> otherwise provides connections of improved security. While DDR can be
> blocked by an on-path attacker, a successful upgrade can be trusted to be
> an entity designated by the original resolver owner.
>

I don't agree with this assessment.  When the unencrypted resolver is
identified by a private IP, both versions are susceptible to capture and
forgery by an on-path attacker.  When it has a public IP or name, neither
version is.

> This PR introduces a mechanism where that is not true.
>

The difference is much subtler.  In draft-01, private IP upgrade is
vulnerable to capture by any on-path attacker.  In PR #11, private IP
upgrade is additionally vulnerable for a short time window after an on-path
attacker ceases to be on-path.  This time can be driven to ~zero by
revalidating the designation before each query, but I think revalidating
every few minutes is likely to be sufficient in practice.

If PR #11 enables significantly broader use of encrypted DNS, as seems
likely, I think it would represent an improvement to overall security.

Since clients will have different opinions on the need to support DDR as it
> is currently defines versus this PR, we should provide them as separate
> documents to avoid clients deploying only partial standard support (as it
> seems likely many will choose to not support this option).
>
>
Since the protocol elements are unchanged, one possibility would be to name
client profiles with different acceptance criteria.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 17 Jun 2021 00:36:45 +0000

> Perhaps.  I think we need more WG input on which use cases are most relevant.

Of course; this is a WG document now. I’m stating my opinions since I do not see consensus one way or the other yet and Chris suggested on GitHub that we should bring discussion on this PR to the list.

> When the unencrypted resolver is identified by a private IP, both versions are susceptible to capture and forgery by an on-path attacker.

There’s a significant difference: with DDR, the private IP address cannot send you to an encrypted resolver unless it is hosted on the exact same IP address. This means that the recipient of your encrypted traffic will be the same recipient you were going to be using without DDR. With your proposal, a forged CNAME may result in the traffic being sent to an attacker who was able to forge a single DNS response for some amount of time over encryption.

Not only would this be undetectable until after it is over, it would also be impossible to determine which CNAME was the attacker without some prior knowledge or expectation regarding the network. Did the CNAME change from valid to invalid? Invalid to valid? Valid to valid because it was a by-design update to the resolver by the network operator? Invalid to invalid because one attacker replaced another?

> When it has a public IP or name, neither version is.

My reading of your PR is that the “validate by IP in SAN” mechanism is simply expressed via the indirection of “Validation Identity” when the original unencrypted resolver is known by a public IP address. If that is the case, then I would agree in that this is trivially true (your PR doesn’t change this scenario).

> In PR #11, private IP upgrade is additionally vulnerable for a short time window after an on-path attacker ceases to be on-path.

This is the difference in security bar I am objecting to. DDR as it stands will never result in an encrypted connection to an unintended party (assuming certificate ownership is secure, the same bar set for general HTTPS usage). Your PR undoes that promise in a way that can only be limited, not eliminated. That seems like a different trade-off that deserves its own space.

> If PR #11 enables significantly broader use of encrypted DNS, as seems likely, I think it would represent an improvement to overall security.

I whole-heartedly disagree with this mentality. Encryption alone is not equal to security. It can in fact be used to keep genuine owners away from their own data (ransomware as a storage example).

Silly example: if we got 100% adoption of encrypted DNS by having all existing clients establish DoH connections to doh.attacker.example, that would obviously not represent an improvement to overall security.

As that silly example illustrates, choice in resolver matters. The purpose of DDR is to ensure that the existing choice in resolver is not changed as defined by the existing chosen resolver. If we allow that trust to be broken _sometimes_ just so we can pump encryption numbers, I think that would be a failure. In Chris Box’s example (maybe provided offline? I do not recall) of defending the client against a compromised peer on the same network which uses local network DNS with no DNR or CE/CPE updates, your PR could just as easily result in that compromised client keeping my DNS traffic for themselves away from the visibility of any on-network inspection mechanisms thanks to the use of encryption.

This is why the 85% problem is so hard: there _is_ no resolver choice identity to strongly rely upon (since 85% case doesn’t include hosting encrypted DNS on the same local IP address). Hence, it deserves a separate consideration of security and functionality trade-offs in my opinion. If the WG disagrees, I think your suggestion of strongly defining different use profiles within the document would make sense, but I still prefer separate standards given the significantly different target scenarios.

Thanks,
Tommy

From: Ben Schwartz <bemasc=[email-masked]>
Sent: Wednesday, June 16, 2021 9:36 AM
To: Tommy Jensen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Add] [EXTERNAL] I-D Action: draft-ietf-add-ddr-01.txt

On Wed, Jun 16, 2021 at 11:47 AM Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrote:
...
Hey Ben,

I appreciate your efforts in keeping up with the base draft, but I think your proposal is best served by a separate document.

Perhaps.  I think we need more WG input on which use cases are most relevant.

The expanded scope it introduces significantly lowers the security posture of DDR overall, which you indirectly acknowledge in the text:

I do not think we should be trying to add this to a standard that otherwise provides connections of improved security. While DDR can be blocked by an on-path attacker, a successful upgrade can be trusted to be an entity designated by the original resolver owner.

I don't agree with this assessment.  When the unencrypted resolver is identified by a private IP, both versions are susceptible to capture and forgery by an on-path attacker.  When it has a public IP or name, neither version is.

The difference is much subtler.  In draft-01, private IP upgrade is vulnerable to capture by any on-path attacker.  In PR #11, private IP upgrade is additionally vulnerable for a short time window after an on-path attacker ceases to be on-path.  This time can be driven to ~zero by revalidating the designation before each query, but I think revalidating every few minutes is likely to be sufficient in practice.

If PR #11 enables significantly broader use of encrypted DNS, as seems likely, I think it would represent an improvement to overall security.

Since the protocol elements are unchanged, one possibility would be to name client profiles with different acceptance criteria.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 16 Jun 2021 21:49:35 -0400

On Wed, Jun 16, 2021 at 8:36 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:
...

> > In PR #11, private IP upgrade is additionally vulnerable for a short
> time window after an on-path attacker ceases to be on-path.
>
>
> This is the difference in security bar I am objecting to. DDR as it stands
> will never result in an encrypted connection to an unintended party
> (assuming certificate ownership is secure, the same bar set for general
> HTTPS usage).
>

When there is an on-path attacker and the unencrypted resolver is
identified by a private IP, DDR-01 results in an encrypted connection to an
unintended party.

Your PR undoes that promise in a way that can only be limited, not
> eliminated.

I don't think it's nearly so clear-cut.  For example, in DDR-01, an on-path
attacker can point all requested domains to attacker-controlled IPs with
long TTLs, allowing them to stay on-path for application traffic long after
the DNS attack is over.  If the client uses any insecure protocols (e.g.
HTTP), of course much worse attacks are possible.

> I whole-heartedly disagree with this mentality. Encryption alone is not
> equal to security.
>

The modern web is powered almost entirely by Domain Validated
certificates.  Unlike the classic Organization Validated certificates,
these are highly vulnerable to a transient on-path attacker, who can
instantly acquire certificates and persist their attack for months.
Nonetheless, the modern web, where a majority of traffic uses HTTPS with DV
certs, is much more secure than the old web where 10% of sites used HTTPS
with OV certs, and 90% were unencrypted.

I think a similar dynamic applies here.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 17 Jun 2021 05:18:11 +0000

> When there is an on-path attacker and the unencrypted resolver is identified by a private IP, DDR-01 results in an encrypted connection to an unintended party.

It results in an encrypted connection to the exact same IP address the client would have otherwise sent unencrypted traffic to anyway. The attacker must be present for all traffic it wants to see/manipulate in both cases. PR#11 adds the ability for this to occur but to a different, possibly off-network, IP address and will continue reaping the benefits for some amount of time after leaving the local path. I argue that is a significantly worse security posture.

> For example, in DDR-01, an on-path attacker can point all requested domains to attacker-controlled IPs with long TTLs, allowing them to stay on-path for application traffic long after the DNS attack is over.

Assuming you mean an attacker on the encrypted path, this requires that either the client establishes and uses a connection to an attacker’s encrypted resolver or that an attacker compromises the encrypted resolver itself, becoming the endpoint (ignoring an attacker who can break TLS, as that attack renders all mechanisms we have moot). The former is prevented by the IP address validation (and scope limiting DDR to those identities a TLS cert can cover); the latter is unrelated to the discovery mechanism used to connect to the encrypted resolver. No discovery mechanism will protect a client against an attacker taking over their recursive resolver.

> I think a similar dynamic applies here.

DV versus OV is resource-cost prohibitive: one is harder than the other. DNR versus PR#11 is time-cost prohibitive: one would be possible right away and the other will be possible eventually. Meaning as time goes on and CE/CPE are sold supporting DNR, networks will be able to advertise whatever encrypted resolver config they want over DHCP/RA without any additional bootstrapping needed by (or attack vectors exposed to) clients. As the same time goes on, the costs of DV versus OV remain the same in ratio (manual verification is always going to be much harder/expensive than automatic).

You’re correct that both PR#11 and DV certs are examples of weaker security postures in the hopes of increasing encryption adoption. However, one is to bring encryption that would otherwise never occur (as the OV bar is too high for many “mom and pop” size domain owners); the other is to bring encryption that could otherwise eventually occur (the 85% problem is rooted entirely in the inability to modify CE/CPE right away faster than hardware turnover in the wild).

In fact, I think this is a great example of why DDR and PR#11 should remain separate. The strength of the ownership guarantee provided by each ownership verification method are significantly different; the same is true for DNS encrypted resolver discovery. One could say the end user will only see “green padlock” or “secure DNS” but under the hood they are very different mechanisms. Why define them together in a single bucket?

Thanks,
Tommy

Sent: Wednesday, June 16, 2021 6:50 PM

On Wed, Jun 16, 2021 at 8:36 PM Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrote:
...
> In PR #11, private IP upgrade is additionally vulnerable for a short time window after an on-path attacker ceases to be on-path.

This is the difference in security bar I am objecting to. DDR as it stands will never result in an encrypted connection to an unintended party (assuming certificate ownership is secure, the same bar set for general HTTPS usage).

When there is an on-path attacker and the unencrypted resolver is identified by a private IP, DDR-01 results in an encrypted connection to an unintended party.

Your PR undoes that promise in a way that can only be limited, not eliminated.

I don't think it's nearly so clear-cut.  For example, in DDR-01, an on-path attacker can point all requested domains to attacker-controlled IPs with long TTLs, allowing them to stay on-path for application traffic long after the DNS attack is over.  If the client uses any insecure protocols (e.g. HTTP), of course much worse attacks are possible.

> If PR #11 enables significantly broader use of encrypted DNS, as seems likely, I think it would represent an improvement to overall security.

I whole-heartedly disagree with this mentality. Encryption alone is not equal to security.

The modern web is powered almost entirely by Domain Validated certificates.  Unlike the classic Organization Validated certificates, these are highly vulnerable to a transient on-path attacker, who can instantly acquire certificates and persist their attack for months.  Nonetheless, the modern web, where a majority of traffic uses HTTPS with DV certs, is much more secure than the old web where 10% of sites used HTTPS with OV certs, and 90% were unencrypted.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 17 Jun 2021 10:32:17 -0400

On Thu, Jun 17, 2021 at 1:18 AM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> > For example, in DDR-01, an on-path attacker can point all requested
> domains to attacker-controlled IPs with long TTLs, allowing them to stay
> on-path for application traffic long after the DNS attack is over.
>
>
>
> Assuming you mean an attacker on the encrypted path, this requires that
> either the client establishes and uses a connection to an attacker’s
> encrypted resolver or that an attacker compromises the encrypted resolver
> itself, becoming the endpoint (ignoring an attacker who can break TLS, as
> that attack renders all mechanisms we have moot).
>

I'm referring to the private IP case, where an on-path attacker can
impersonate the resolver or simply disable the upgrade.

My point is that DDR-01's post-compromise security, which you are trying to
preserve, is already substantially broken.

DV versus OV is resource-cost prohibitive: one is harder than the other.
> DNR versus PR#11 is time-cost prohibitive: one would be possible right away
> and the other will be possible eventually. Meaning as time goes on and
> CE/CPE are sold supporting DNR, networks will be able to advertise whatever
> encrypted resolver config they want over DHCP/RA without any additional
> bootstrapping needed by (or attack vectors exposed to) clients. As the same
> time goes on, the costs of DV versus OV remain the same in ratio (manual
> verification is always going to be much harder/expensive than automatic).
>
>
>
> You’re correct that both PR#11 and DV certs are examples of weaker
> security postures in the hopes of increasing encryption adoption. However,
> one is to bring encryption that would otherwise never occur (as the OV bar
> is too high for many “mom and pop” size domain owners); the other is to
> bring encryption that could otherwise eventually occur (the 85% problem is
> rooted entirely in the inability to modify CE/CPE right away faster than
> hardware turnover in the wild).
>

I think this is an interesting question for the WG: is DNR deployment just
a matter of time?  How long do we expect it to take to reach substantial
deployment of DNR?

It seems to me that we may not be able to assume universal deployment of
DNR.  Some WG members have noted that routers often need to start sending
the local DHCP/RA before receiving the upstream configuration, thus
necessitating a local DNS forwarder.  This arrangement could use DNR to a
local forwarder (given enough CPU and RAM), but not "end to end" to an
upstream resolver like PR #11.  DNR also seems to require operating system
modifications, to read the new DHCP/RA options and convey their contents to
any stub resolvers.

Also, DNR overrides DDR entirely, so if DNR really is deployed broadly,
then security concerns about DDR will be moot.

In fact, I think this is a great example of why DDR and PR#11 should remain
> separate. The strength of the ownership guarantee provided by each
> ownership verification method are significantly different; the same is true
> for DNS encrypted resolver discovery.
>

I think there's already a much larger divergence within DDR-01, between the
optional opportunistic client behavior and the fully authenticated modes.

> One could say the end user will only see “green padlock” or “secure DNS”
> but under the hood they are very different mechanisms.
>

In the case we are discussing (private IP), I think it would be a grave
mistake to present the user with any claim that the DNS connection is
"secure".  It is not, in either version.

> Why define them together in a single bucket?
>
>
>
> Thanks,
>
> Tommy
>
>
>

---

From: tirumal reddy <[email-masked]>
Date: Fri, 18 Jun 2021 16:24:10 +0530

On Thu, 17 Jun 2021 at 20:02, Ben Schwartz <bemasc=
[email-masked]> wrote:

> My point is that DDR-01's post-compromise security, which you are trying
> to preserve, is already substantially broken.
>
> upstream resolver like PR #11.
>

Home routers can receive upstream DNS configuration using DHCP (for
example, see Figure 1 in
https://datatracker.ietf.org/doc/html/draft-boucadair-opsawg-add-encrypted-dns-02)
or a managed home router can receive the upstream DNS configuration using
the CPE WAN management protocol (TR-069).

-Tiru

> DNR also seems to require operating system modifications, to read the new
> DHCP/RA options and convey their contents to any stub resolvers.
>
> In fact, I think this is a great example of why DDR and PR#11 should
>> remain separate. The strength of the ownership guarantee provided by each
> I think there's already a much larger divergence within DDR-01, between
> the optional opportunistic client behavior and the fully authenticated
> modes.
>
>