IETF Logo Mail Archive

Re: [Doh] panel discussion on DoH/DoC

Valentin Gosu <valentin.gosu@gmail.com> Thu, 07 February 2019 14:20 UTC

Return-Path: <valentin.gosu@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666F128B36 for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 06:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bc5pMVdmBh1 for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 06:20:45 -0800 (PST)
Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1961289FA for <doh@ietf.org>; Thu, 7 Feb 2019 06:20:44 -0800 (PST)
Received: by mail-it1-x12b.google.com with SMTP id z7so80110iti.0 for <doh@ietf.org>; Thu, 07 Feb 2019 06:20:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V5sCW6xY+r9F6szWcjsMzEUOnoKiMzxDrv5W75BwA34=; b=tw3lSrkHAW2LrKWxTdsE54Ljth96L0Ejym5zm8t6pW+aZmfe0vomLMbR1XBXlVG8E0 4fo7duD4hAJVwbtLNjRMDW/19NK6RcSKBtmjlAF3/q1jf6Y8pqthnODtqS6I5oauURE4 2NBBQpymmFsjexJ89DPoEu5yIaQXFV9AOISTZacB0Fe3vOfvYlgV2uiVF1diB5u1ujen UdBZI5U8J5j5Ork/cTlblfHJ7vZerpr8MjiS/2XkClsscDqO+eIwoSf3Hw+/9kK4XBLv zty5rH5gEIx9mCL0CwXp+UxRmeVIVMvZ+OM9imjcx9oyLbpR4oSDtJrbvq0nHs97wg/U Fevg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V5sCW6xY+r9F6szWcjsMzEUOnoKiMzxDrv5W75BwA34=; b=uM2In8QPc7S3zNFKANT9KjJE4vijsK02CBXd7mMeRvH8ss0weB95Q1FP6H9LnYYprN rNoszecjjWvcmM1yamnn7LiRq6+eWcF8g+crL+jX5ZFQfYPliTJBgH3tISyBSGHKmA77 M8zXX7KXp6Uh4IGpMt8or7u2isXB5RAr5tegNOMuU+s3jR8uDfT71iNx2tJJ/YipxGkh dralktiPCM2dunVOoqB9XEJuKL+4vvGfa3drTjUfcECLfMEL2cPPyu0huHc8YnX53c8f mYDanG8EMXCMA7JeaWo/6tWuKYEAfDi48MIbKSAsaZa6wAwXe1VRpROCRVMzuhKR6iuk fC7A==
X-Gm-Message-State: AHQUAuYiovF0aU1sGXhjDmNObMsLIhJQPNPhunqH7dAqGPy5/pnsty// HXU58NMVg/NQNYeds+63OKylqIvH6e9He8+ewSU9Ja6o
X-Google-Smtp-Source: AHgI3IahiT9VEnvYKb4H3iznFCnopIL8OgM+8dkIgX6RvPVV0ayMZgreE/zDe320QDIt1Bb7kXXM9ER0wTvcNuc9j/k=
X-Received: by 2002:a24:434f:: with SMTP id s76mr3494816itb.123.1549549244207; Thu, 07 Feb 2019 06:20:44 -0800 (PST)
MIME-Version: 1.0
References: <20190207105106.GB1772@server.ds9a.nl> <C7C3BAF7-4BD4-4EE2-B3F2-1F8B49222980@fugue.com> <20190207130313.7g7hf4swaopnr75e@nic.fr> <FD7BFAFF-88B9-49BF-A652-3649ADCD53F9@fugue.com> <1630977697.16646.1549545429521@appsuite.open-xchange.com> <C4198B87-FC5C-45BE-B7A0-CA50E796DDD4@fugue.com>
In-Reply-To: <C4198B87-FC5C-45BE-B7A0-CA50E796DDD4@fugue.com>
From: Valentin Gosu <valentin.gosu@gmail.com>
Date: Thu, 07 Feb 2019 15:20:32 +0100
Message-ID: <CACQYfiJJf792QeqBt+ga0CKYvZd2iL2Z5xh9f6ts=SHQ7d5XVw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Vittorio Bertola <vittorio.bertola@open-xchange.com>, doh@ietf.org
Content-Type: multipart/alternative; boundary="000000000000435b1805814e8c00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/l4dWAV7L1cYK_d4Uogg8rmaz2a4>
Subject: Re: [Doh] panel discussion on DoH/DoC
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 14:20:47 -0000

On Thu, 7 Feb 2019 at 14:23, Ted Lemon <mellon@fugue.com> wrote:

> On Feb 7, 2019, at 8:17 AM, Vittorio Bertola <
> vittorio.bertola@open-xchange.com> wrote:
>
> Which of course depends on a) having a practical possibility of choice
> among many browsers having many different policies, and b) the browsers
> letting you configure your resolver freely.
>
>
> Yes, it does.   UTSL?
>
> On Feb 7, 2019, at 8:16 AM, Shane Kerr <shane@time-travellers.org> wrote:
>
> In theory one could send DoH queries to the server where you were getting
> an HTML page from, for any names that need resolution on that page. This
> would be a anti-DoC, indeed probably more decentralized than DNS itself is
> today.
>
> If this model requires DNSSEC then it's not even that horrible, since web
> server operators would not be able to spoof or hijack DNS names.
>
>
> Except that perhaps I want to block, I don’t know, name resolution for
> various ad bug sites?   And then if the browser has a secure way past my
> block, suddenly I’m seeing ads again.   Whether you believe that ads are
> immoral or not, the fact is that this wrests control away from the end user.
>

I think a very important point to make is that the existence of the DoH RFC
does not affect these sort of usecases at all. If an ad site wanted to load
ads without being constrained by DNS it could always hardcode IP addresses,
or use their own homegrown variety of DNS over HTTP(S) with the server of
their choice. The same is true for IoT devices. And even for browsers. If
Google wanted to perform all DNS resolutions using "frankenDNS over gQUIC",
there's hardly a way you can stop them.

Where having a DoH RFC is immensely helpful is that you now have lots
compatible server and client implementations. If you want to increase your
privacy in a coffee shop, just point your stub resolver to a DoH server -
be it Cloudflare, Google, or your own pi-hole that you have at home.
And when browsers implement DoH, it's easier to have a choice of DoH
servers, because implementations follow the same RFC.

v2.23.0 | Report a Bug | By Email