Re: [Doh] New: draft-livingood-doh-implementation-risks-issues

[Stephane Bortzmeyer <[e-mail]>]

On Sat, Mar 09, 2019 at 01:23:56AM +0000,
 Livingood, Jason <[e-mail]> wrote 
 a message of 1765 lines which said:

> FYI that this document has posted. I have requested 10 mins of
> agenda time in the DOH WG at IETF 104.

A few remarks (summary: a real issue but the draft obscures it, by
piling a lot of questionable arguments, and by lacking rigor in
separating DoH from the general issue of public DNS resolvers).

> Separating the Protocol from Implementation Issues

There have been already discussions about the need to discuss
separately DoH-the-protocol and DoH-the-deployment. For the latter,
Bert Hubert
<https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/>
suggested DoC (DNS-over-Cloud).

> Network operators, ranging from ISPs to enterprises, schools, and
> others work hard to provide outstanding DNS and network performance,

Nice but clearly false. One of the reasons why many users switch to
public DNS resolvers is because many local networks and ISP do a lousy
job (specially in some parts of the world). Not to mention those who
simply announce 8.8.8.8 trough DHCP...

> In addition, most also provide DNS-based services such as opt-in
> parental controls for consumers or malware/security protection in
> enterprises, content filtering in schools, etc.

"most"? I doubt it. Source?

> the current Centralized DoH implementation model does not appear to
> make it possible for these operators to continue to play a value
> added role in the delivery of network services

Some people may consider that this is not something we want from the
ISPs. "value added" is often the code word for violations of network
neutrality.

> with 30 companies being responsible for 30% of global traffic

A very questionable metric. If you care only about bytes, video
providers will always win. But other metrics could be used: is a video
of a cute kitten more important than a PDF document which is a
multi-million dollars contract?

> The Dyn attack provides a vivid illustration of how DNS
> infrastructure vulnerabilities - and DNS space concentration - can
> wreak havoc on the stability of the Internet."

Is it really relevant, since it was an attack on authoritative DNS
servers? Having lot of local resolvers would not have changed its
consequences.

> DNS blocklists, which are one of the primary and most effective ways
> to protect a network and its users against malware, phishing, spam,
> DDoS attacks, etc.

Can you explain how a blocklist on the DNS resolver protects against
spam and dDoS?

> Loss of Parental Controls or other Content Controls

The draft seems to assume that lying DNS resolvers are a good thing
(politically and technically) but I don't think there is an IETF
consensus here.

> Disruption of Legally-Mandated National-Level DNS Blocks

It think it is a feature of DoH, not a bug. In Europe, for instance,
many users switch to public DNS resolvers precisely to be able to
bypass the lying resolver.

> Smaller DNS Labor Market

Certainly we, at the IETF, don't work just to preserve our jobs!

Really, you pile way too many arguments to kill "centralized DoH", and
some are really weak.

> This document makes the following recommendations

The most important is missing: help developers to create DoH servers
that can be easily installed and managed so, instead of a few DoH
providers, we can have many of them. (Currently, there is no easy way
to download and install a DoH server.)

> ICANN legal department assessment:
> ICANN currently required Generic Top Level Domain (gTLD) operators
> to meet certain technical criteria, as noted in Specification 6,
> Part 1.1 of their Registry Agreement [48].  ICANN may need to
> consider whether those DNS operators should or must add support for
> DoT and/or DoH in the future

Besides the fact that ICANN already suffers from a serious mission
creep, gTLD operators operate authoritative servers so I don't see why
you mention DoH or DoT, which are currently only for the
stub-to-resolver link.

> Develop Centralized DoH Data Privacy Guidelines/Frameworks

draft-reid-operator-doh
draft-dickinson-bcp-op
draft-dickinson-doh-dohpe