Jacob Hoffman-Andrews wrote:
I agree: The EDN0 Client ID draft seems quite bad from a privacy
perspective, and I believe it should not be adopted.
More broadly, enforcing content blocks with DNS is an anti-pattern. If
we're assuming that the entity doing the content blocking has
administrative access to DNS clients, they can simply install content
blockers there.
i think content blocking is a reach -- in your interpretation.
this is about CDN. as in, how to decide which address record set to give
a dns client, given that all you know is the recursive server address,
yet you're trying to implement policy for an expected tcp session that
might immediately follow.
... The draft even acknowledges the ineffectiveness of DNS-based content
blocking:
DNS filtering products are easy circumvented and should not be
considered real security measures. With commonly available tools it
is trivial to discover the non-filtered DNS responses and use them in
place of the filtered responses.
So it seems incorrect to propagate a privacy-harming DNS extension that
is ineffective at its stated goals.
your reasoning is flawed. there are indeed privacy problems here. the
data miners and data scientists and aggregators of the world will have a
much better idea which end user a dns request was generated for, in the
case where all they see is above the recursive not below, and this
option is used. that's a fine reason to oppose adoption.
but it's got precious little to do with content filtering. as i wrote in
a recent circleid article, dns-level content filtering will only work
when end users believe that the recursive name server operator has
aligned interests, and for that reason one shouldn't say "it's easy to
bypass" but rather "end-user cooperation is required."
this draft would be more adoption-worthy if it used similar language.
see also:
http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
