[Mud] more from the ADD debate

In case you missed this long tussle.

On Fri, Jul 26, 2019 at 11:06 AM Ted Lemon <mellon@fugue.com> wrote:

>
>
> On Jul 26, 2019, at 10:50 AM, Brian Dickson <brian.peter.dickson@gmail.com>
> wrote:
>
>
>    - One approach to enforcing the policy has a larger scope than the OS.
>    It is to view DoH itself as the problem, and ask, how can we put the DoH
>    genie (djinn) back in the bottle?
>
> The djinn was never in the bottle in the first place. If this discussion
> is going to continue to entertain the fantasy that malware isn’t already
> doing this, it’s not likely to be very useful.
>

One important distinction about malware "doing this": prior to the scenario
where DoH (to an independently-operated resolver) was used, it was possible
to detect this malware activity by correlation between DNS queries and TLS
connections.

In order to establish a TLS connection, the client app needs to do a DNS
query to identify the IP address of the server to which it plans to connect..

A hypothetical anti-malware system with integration to the DNS query feed,
would be aware of specific clients requesting specific DNS records, and the
TTLs of the responses.

Connections not conforming to tuples of (current time, client IP, server
IP, TTL expiry time) would be detectable and alert-able. (Additional
information on connections' SNI and servers' names allows much greater
accuracy, but if/when ESNI happens, this signal goes away.)

In an environment where DNS resolver choice cannot be detected or enforced,
negates this model, particularly if all DNS query traffic becomes
unobservable to the hypothetical anti-malware system.

This is a change to the threat detection and blocking environment, and
exists only when encrypted DNS is commingled with HTTPS traffic.

Brian

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

[Mud] more from the ADD debate

Attachment: signature.asc