Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure"

> On 17 Nov 2019, at 18:48, S Moonesamy <sm+ietf@elandsys.com> wrote:
> 
> Hello,
> At 10:53 PM 12-11-2019, Andrew Campling wrote:
>> In the DNS section, it is disheartening to read the IAB stating that "[a DNS resolver] returning the wrong (or no) address breaks the trust that users have in this infrastructure", after having spent months on the ADD list and elsewhere to explain that there are indeed lots of use cases in which users expect, or even actively request, that their resolver applies filters to the responses. In some cases it is actually the opposite - if I acquire a DNS-based service to prevent any accidental connection to malware-infected websites and then I get malware, that's when I lose trust in my DNS resolver; same for parental controls.
> 
> The position, in the past, was that it was important to preserve the chain of trust instead of allowing someone along the path to change the information published in DNS.  There are use cases where the changes are done for valid reasons, e.g. the user does not wish to download malware.  What are the unintended consequences of supporting such cases?

The unintended consequences don't come from "supporting the use case" per se, they come from the technical details of the approach used to do so. For example:

For your malware example, "change DNS records by intercepting queries between the client and the recursive resolver and inject NXDOMAIN for malware domains" is one way to implement such a thing. The unintended consequences of this are "you can't deploy DNSSEC", "anyone on the same path can do the same interception, maybe even to add malware", and so on.

Another way to support the same use case would be to add endpoint defenses to the browser for web-based malware: in this case the browser checks URLs against a blocklist. The tradeoff here is that you need to touch every browser, and a possible unintended consequence here is that the infrastructure to distribute the blocklists is a potential further centralization of the architecture.

Cheers,

Brian

> Regards,
> S, Moonesamy
> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss