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.

——

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=40comcast.com@dmarc.ietf.org> wrote:
> 
> 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/ <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 -  ADD@IETF.ORG <mailto:ADD@IETF.ORG>
>  
> Regards
> ADD Co-chairs Glenn Deen, David Lawrence
>  
> -- 
> Add mailing list
> Add@ietf.org <mailto:Add@ietf.org>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>