<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   I am a bit reluctant to take over this list (which I subscribed just for lurking and learning something on DNS operations) with yet another DoH discussion. So I will reply, but please moderators let me know if I'd better stop.
   <br>
  </div>
  <blockquote type="cite">
   <div>
    Il 29 marzo 2019 alle 16.32 David Conrad <
    <a href="mailto:drc@virtualized.org">drc@virtualized.org</a>> ha scritto:
   </div>
   <div>
    <br>
   </div>
   <div>
    I am not justifying anything. I am merely pointing out a reality that some network operators, state-based actors, and infrastructure providers took actions that caused a set of counter-actions. Just as the green card lawyers caused the creation of anti-spam tools that blocked entire ISPs because of the actions of a few of the ISPs customers. Or RPZ tools that allow for the blocking of entire TLDs because of the actions of a few registrars.
   </div>
   <div>
    <br>
   </div>
   <div>
    Do you find those tools unhelpful and divisive as well?
   </div>
  </blockquote>
  <div>
   I'd be happy to have a discussion on this topic (even more off topic, though) - in fact, having run my own small email server for a couple of decades, I do have a problem with how email reputation and blacklisting is implemented without giving reasonable redress mechanisms to senders, and how hard this makes for small systems to continue delivering their messages, though again, I have to note that the first and foremost operator that often blocks small legitimate senders for whatever reason without providing easy remediation is not an ISP - it is Gmail.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   This said, your analogy doesn't work here, because anti-spam tools block specific ISPs that do not comply with reasonable anti-abuse procedures to keep their malicious customers under control, i.e. because they do not behave; but those tools do not block the other ISPs that instead comply. No anti-spam tool blocks all ISPs, no RPZ blocks all TLDs, good and bad alike. You asserted instead (correct me if I'm wrong) that it is right to bypass all ISPs because some of these operators are bad, and who cares about those that are good. This is not the same concept.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   Also, I would like to point out that, in all conflicts of any type, each of the two clashing parties claims that it's the others that are evil, and their are just reacting with "counter-actions" to their wrongdoings. If you talk with governments, even democratic ones, they will say that they are just reacting to the Internet industry's refusal to deal effectively with dangerous and illegal content, or to respect people's privacy and not track them and sell them out to advertisers at every occasion. This kind of "it's all their fault" claim is also unhelpful and makes conflicts deeper and deeper.
   <br>
  </div>
  <div>
   <br>
  </div>
  <blockquote type="cite">
   <div>
    <br>
   </div>
   <div>
    DOH exists partly because there was a risk of a vulnerability in the underlying infrastructure and an in-application mechanism was relatively easy to deploy that addressed that risk.
   </div>
   <div>
    <br>
   </div>
   <div>
    Do you deny that risk exists?
   </div>
  </blockquote>
  <div>
   Absolutely not, and I'd be happy to see all DNS connections encrypted. However, I do not accept that this risk is the only one, or even the worst one. Having all my DNS data, the list of all the destinations I visit, go to global companies that have a business model based on profiling me is a much worse privacy risk, and if you address the first risk by making the second worse, that's not a good solution.
   <br>
  </div>
  <blockquote type="cite">
   <div>
    <br>
   </div>
   <div>
    An implication of the solution to that risk is to cause all infrastructure providers to be assumed by users of a particular application to be distrusted by default.
   </div>
  </blockquote>
  <div>
   If so, then it's not a well designed solution.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   Also, another fallacy of this discussion is the statement that the users of the browsers distrust ISPs and are asking for this. This is, as a minimum, undemostrated, and as a maximum, false; it is the *makers* of the browsers that distrust all ISPs, pretending to do this for the users. In fact, if for example you read the comments to this article in German reporting the IETF discussion:
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   <a href="https://www.heise.de/newsticker/meldung/DNS-over-HTTPS-Ein-Problem-geloest-mehrere-neue-geschaffen-4350674.html">https://www.heise.de/newsticker/meldung/DNS-over-HTTPS-Ein-Problem-geloest-mehrere-neue-geschaffen-4350674.html</a>
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   you will find that many of them are against this idea. So while some users may like the idea, some others don't, and we should stop saying what users want without facts to support it.
   <br>
  </div>
  <blockquote type="cite">
   <div>
    The alternative is to trust some but not others. What is your solution to distinguish between trusted and non-trusted infrastructure providers? How will the proverbial grandmother deploy your solution?
   </div>
  </blockquote>
  <div>
   My grandmother chooses who to get Internet access from, among one of many providers that are available here. This is already a statement of trust that is at least as valid as the one implicit in using a browser - possibly more, because it is explicit and it implies signing a contract and paying money every month, while you only have a very limited choice of browsers and you often just get them preinstalled by someone else on your device, possibly because of business deals between the device maker and the browser maker (which, not rarely, are actually the same company).
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   At the same time, I do not object if other users think that they cannot trust the ISP that they chose. In other (less regulated and less fortunate) parts of the world, that might be the norm. So I am fine if other users want to employ software that bypasses their ISP entirely. What I am not fine with, is having that model forced upon me and all the people around me as a new default, without proper information or consent.
  </div>
  <blockquote type="cite">
   <blockquote type="cite"></blockquote>
   <div>
    Since I appear to be mistaken: if the registrars, registries, or ICANN can be replaced by some new technology implemented by browser vendors, disrupting the existing system and creating different gatekeepers to identification on the Internet, then it is up to Internet users, not me, you, the DNS cabal, the IETF, etc., to decide the “winners”. Pretending that there aren’t aspects of the current system that caused the creation of new gatekeepers/alternate technology is a waste of time.
   </div>
  </blockquote>
  <div>
   The problem is that what is being done is actively restricting user choice. Today, if a user wants to direct their queries to a specific resolver, he/she just needs to change a single setting in the OS. With DoH, the user is supposed to configure manually each and every application, dozens of them - so the practical result will be that people will just go with the defaults. Moreover, the application might not even provide a configuration option, or might restrict it to their own list of friends, sorry, trusted partners; and might not even inform users on what it is doing, or ask for consent.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   So, I totally agree that users should choose freely and have the final word - that's actually the topmost recommendation in the Internet draft I submitted. I do not agree that what Mozilla is doing puts users in charge; in fact, it does the opposite.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div class="default-style">
   Regards,
   <br>
  </div>
  <div class="io-ox-signature">
   <p>-- <br class=""></p>
   <pre class="">Vittorio Bertola | Head of Policy & Innovation, Open-Xchange<br><a href="mailto:vittorio.bertola@open-xchange.com">vittorio.bertola@open-xchange.com</a> <br>Office @ Via Treviso 12, 10144 Torino, Italy</pre>
  </div> 
 </body>
</html>