Subject: [Add] WG Adoption Call draft-schwartz-add-ddr-forwarders

From: "Deen, Glenn" <[email-masked]>
Date: Mon, 11 Apr 2022 16:57:53 +0000

ADD

This is a WG Adoption call for draft-schwartz-add-ddr-forwarders

Draft link https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/

This adoption call will last 2 weeks until Monday April 25th 2022

Please submit comments to the ADD mailing list -  [email-masked]<mailto:[email-masked]>

Regards
ADD Co-chairs Glenn Deen, David Lawrence

---

From: tirumal reddy <[email-masked]>
Date: Wed, 13 Apr 2022 14:37:09 +0530

I support adoption of this draft. I am willing to review and contribute
text.

-Tiru

On Mon, 11 Apr 2022 at 22:28, Deen, Glenn <Glenn_Deen=
[email-masked]> wrote:

> Draft link
> https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/
>
>
>
> Please submit comments to the ADD mailing list -  [email-masked]
>
>
>
> Regards
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Winfield, Alister (Senior Solutions Architect)" <[email-masked]>
Date: Wed, 13 Apr 2022 09:42:12 +0000

I support adoption of this draft.

From: Add <[email-masked]> on behalf of tirumal reddy <[email-masked]>
Date: Wednesday, 13 April 2022 at 10:08
To: Deen, Glenn <Glenn_Deen=[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [EXTERNAL] Re: [Add] WG Adoption Call draft-schwartz-add-ddr-forwarders
I support adoption of this draft. I am willing to review and contribute text.

-Tiru

On Mon, 11 Apr 2022 at 22:28, Deen, Glenn <Glenn_Deen=[email-masked]<mailto:[email-masked]>> wrote:
ADD

Draft link https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-schwartz-add-ddr-forwarders%2F&data=04%7C01%7Calister.winfield%40sky.uk%7Ce29e84f39fbf42399ef908da1d2d1ebf%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637854377000480913%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9oJq6EBtJzxzZW4C%2FW8jireIXaJ2HFP%2BGri6apz9FHk%3D&reserved=0>

Regards

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=04%7C01%7Calister.winfield%40sky.uk%7Ce29e84f39fbf42399ef908da1d2d1ebf%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637854377000480913%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JCRLJNUdrhtZj4QZ1J9W051C7BlSECfS987WsQx9%2Bvk%3D&reserved=0>
--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to [email-masked]. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 13 Apr 2022 13:59:01 +0200 (CEST)

> Il 11/04/2022 18:57 Deen, Glenn <glenn_deen=[email-masked]> ha scritto:
> 
> 
> 
> 
> 
> ADD
> 
>  
> 
> Draft link https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/ <https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/>
> 
> 
>  
> 
> Please submit comments to the ADD mailing list -  [email-masked] <mailto:[email-masked]>
> 
I support adoption and I will be happy to contribute.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] <mailto:[email-masked]>
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 13 Apr 2022 14:43:51 +0000

I support adoption of this draft and am willing to review and contribute.

-Vinny

ADD

Regards

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 15 Apr 2022 08:48:16 -0700

Tl;dr: I’d like to see more revision and clarity in what this document is actually proposing, along with an understanding of who would use it, before we adopt it. I do not support adoption of the current form of this document.

——

Overall, I find the structure and flow of this document quite confusing. It starts with a terminology section and background, but never quite has a normal introduction that explains what implementations should do.

As discussed in the last ADD meeting, section 3 (which seems to be the important part that actually says that clients may want to just ignore the validation of encrypted servers) needs to have forward references to the concerns and mitigations. Saying that you define a “relaxed validation” policy that just says to ignore everything without telling people to read the functional/privacy/security problems and mitigations is very problematic.

I also suggest that section 3 suggests viable combinations of the mitigations described below. For example, using a trusted list of resolver + user approval. Or being entirely optimistic, but re-checking the designation every five minutes.

Section 4, which is called “naturally compatible”, really is about cases where clients would be ignoring local resolver/forwarder policy unless the local resolver/forwarder blocks all queries for resolver.arpa. This would be more clearly titled as “Policy and Functionality Concerns”. I also don’t think this is something that just “naturally” happens. Yes, forwarders may have configurable block lists, but until every forwarder actually configures their list to add resolver.arpa, a client can’t reasonably start using unvalidated DDR connections without breaking everyone’s local policy.

Section 5 on privacy considerations essentially claims that, since privacy is bad with unencrypted DNS, doing encrypted DNS to an untrusted party isn’t any worse. In light of the security attacks in section 6, I don’t find this convincing. Yes, before my privacy on the local network wasn’t great in that anyone could see my queries. However, the fact that now my queries can be sent to some random and unrelated third party anywhere on the internet doesn’t seem like equivalent privacy. The scope of where data is leaking has grown.

For the section on security considerations (6), I find the mitigation of having trusted resolvers to be far stronger than the “check again every five minutes” approach. You’re discussing a transient attacker that leaves the network, but I think we need to mention a more persistent attacker. If I have a persistent attacker between my forwarder and the ISP resolver, it’s true that it could have always been modifying or monitoring DNS activity from my network. However, it did not necessarily know per-device boundaries, it would have to do more work to rewrite all the traffic itself, and it would also be something that would be more easily detected by looking at packet traces on the network to discover anomalous responses. With unvalidated DDR, it just needs to intercept one kind of query (resolver.arpa), and can point individual clients to communicate with any server it chooses. The attacker’s job becomes significantly easier. We should at least mention this.

I’ll end with a question: what clients plan on implementing these approaches, and in what combinations? I’d prefer to see the document form around recommendations for what clients would realistically do. Just doing opportunistic DDR with no mitigations of any kind is not something that we should even mention or hint at.

Best,
Tommy

> On Apr 11, 2022, at 9:57 AM, Deen, Glenn <Glenn_Deen=[email-masked]> wrote:
> 
> ADD
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 15 Apr 2022 17:51:51 +0000

My concerns closely mirror Tommy's, so I won't say more than that (I knew waiting to reply would pay off :) ). I also opposed adoption at this time, but not on principle of the idea itself. The trade-offs need to be made clear because there was good reason this did not make it into DDR itself.

My previous commitment to help this draft stands (I'll go provide my own review on GitHub for granular suggestions), but I want to be clear that is because of the obvious desire of significant portions of the WG requesting it and wanting to help the WG as a whole. To answer Tommy's question:

> I'll end with a question: what clients plan on implementing these approaches, and in what combinations?

We do not intend to implement this. We believe that simply using the network's resolver without encryption would be better than the unverifiable upgrade alternative. However, I respect that others disagree and that it is within our charter to provide a solution for those who do want to take that trade-off.

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Tommy Pauly
Sent: Friday, April 15, 2022 8:48 AM
To: [email-masked]
Cc: Deen, Glenn <Glenn_Deen=[email-masked]>
Subject: [EXTERNAL] Re: [Add] WG Adoption Call draft-schwartz-add-ddr-forwarders

Tl;dr: I'd like to see more revision and clarity in what this document is actually proposing, along with an understanding of who would use it, before we adopt it. I do not support adoption of the current form of this document.

--

As discussed in the last ADD meeting, section 3 (which seems to be the important part that actually says that clients may want to just ignore the validation of encrypted servers) needs to have forward references to the concerns and mitigations. Saying that you define a "relaxed validation" policy that just says to ignore everything without telling people to read the functional/privacy/security problems and mitigations is very problematic.

Section 4, which is called "naturally compatible", really is about cases where clients would be ignoring local resolver/forwarder policy unless the local resolver/forwarder blocks all queries for resolver.arpa. This would be more clearly titled as "Policy and Functionality Concerns". I also don't think this is something that just "naturally" happens. Yes, forwarders may have configurable block lists, but until every forwarder actually configures their list to add resolver.arpa, a client can't reasonably start using unvalidated DDR connections without breaking everyone's local policy.

Section 5 on privacy considerations essentially claims that, since privacy is bad with unencrypted DNS, doing encrypted DNS to an untrusted party isn't any worse. In light of the security attacks in section 6, I don't find this convincing. Yes, before my privacy on the local network wasn't great in that anyone could see my queries. However, the fact that now my queries can be sent to some random and unrelated third party anywhere on the internet doesn't seem like equivalent privacy. The scope of where data is leaking has grown.

For the section on security considerations (6), I find the mitigation of having trusted resolvers to be far stronger than the "check again every five minutes" approach. You're discussing a transient attacker that leaves the network, but I think we need to mention a more persistent attacker. If I have a persistent attacker between my forwarder and the ISP resolver, it's true that it could have always been modifying or monitoring DNS activity from my network. However, it did not necessarily know per-device boundaries, it would have to do more work to rewrite all the traffic itself, and it would also be something that would be more easily detected by looking at packet traces on the network to discover anomalous responses. With unvalidated DDR, it just needs to intercept one kind of query (resolver.arpa), and can point individual clients to communicate with any server it chooses. The attacker's job becomes significantly easier. We should at least mention this.

I'll end with a question: what clients plan on implementing these approaches, and in what combinations? I'd prefer to see the document form around recommendations for what clients would realistically do. Just doing opportunistic DDR with no mitigations of any kind is not something that we should even mention or hint at.

Best,
Tommy

On Apr 11, 2022, at 9:57 AM, Deen, Glenn <Glenn_Deen=[email-masked]<mailto:Glenn_Deen=[email-masked]>> wrote:

ADD

Draft link https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-schwartz-add-ddr-forwarders%2F&data=05%7C01%7CJensen.Thomas%40microsoft.com%7Cc99f6d804fe2459ae39b08da1ef765fe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856345203480301%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zonFoClHWm%2F8p140lyCyW%2B%2FjvK4qxtmTE7FLlI2qI9o%3D&reserved=0>

Regards

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=05%7C01%7CJensen.Thomas%40microsoft.com%7Cc99f6d804fe2459ae39b08da1ef765fe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856345203530275%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X8j8r2B63SZlJS1Epj43JiyN67wFPIIsxLqfCjuCGU0%3D&reserved=0>