Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ted Lemon <mellon@fugue.com> Mon, 20 August 2018 17:07 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FEC130E37 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 10:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 MPfXNNKLYlmN for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 10:07:22 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 AEC01130E30 for <dnsop@ietf.org>; Mon, 20 Aug 2018 10:07:22 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id d70-v6so8618827ith.1 for <dnsop@ietf.org>; Mon, 20 Aug 2018 10:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=itRps57ftieWUDLTBLE5a66J5JRcOvbSNHMJsB0BY+o=; b=VP5uzYanxiV1l3R/iZZQ/uUllD/T7H4HBhHmMsC3aQ1wp9kzKAoSARVfgxpLiXFJe2 TmYIvL4wGFvu6Cr4eU2Itj0grLRAwAq1Ce8QEcgkwUJaGTrEYE9jW9mDFpiDCXpsnHzA Ecyg3diVsQRiYHrAxLJxFOe8iFOibHa9Jb9Ok0TlMrEC5F1/eGkBnhV8chwTns7ia0Mv drj+yK9Z2gfAtr33JKpH1rw5o9xcmOqaexJexvnMRcKlF8t98DnDzaJtwuYQlMfu1TNW LjfolWALo0w5Mg5jJcaAv/HbIuHVAUYICGYxVz/jQmvhjyv2Q6K/OnRqwn2cdYY3a3// /yCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=itRps57ftieWUDLTBLE5a66J5JRcOvbSNHMJsB0BY+o=; b=a7YWBloFCVyalxjloS7YPx/dPPx+wwzAc3dPYJ7vwGoepdXCY+7iBRGyRtCrZ6G5vO IomWCYOzWe2BJzl8KUNiiqq2oUgynu7c7xANcbOG5mPHLwUBRzvajF589cqRszXu18Yn gGirpmeujqGjrqut+HzqbAppQPP1erOwI92IYjFt1X67bPsdYNXSYckPulYLAitwGQtz BBXjLYFwgOEveLcgxoIh95zzaARrFmND9WnxFtCiP04luMKJ2AfFe/EjwP7k9Kty0ASx dH7YRAs3NAOQgi/pLN4/do8wibOCgHvna7Q5kJEccS9s35ulJLCWQXCTqKwuIHlJUbHy lc9g==
X-Gm-Message-State: AOUpUlGZ/q/W4rf1e0Hge8ftEOuKZgR/c0q21OIRFtbeOIeCQpMMxtOF fd4LFw1m8OElySrFZXb5CN9c2HMxniPZ5me5CFeUAj+6
X-Google-Smtp-Source: AA+uWPyawjXHadJt12DUgwmuWIShrWPFv3O5KcRS7UNxNTpGs3TPCA0GMhcQTU9leV0t+e/q43mJPAvRWo56GtFruBk=
X-Received: by 2002:a24:374d:: with SMTP id r74-v6mr34405562itr.57.1534784841927; Mon, 20 Aug 2018 10:07:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 10:06:41 -0700 (PDT)
In-Reply-To: <5B7AF30F.7040409@redbarn.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <5B7AF30F.7040409@redbarn.org>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 20 Aug 2018 13:06:41 -0400
Message-ID: <CAPt1N1=ad9MyZmHncTfdDV9pPim9cDC=boAFD9UxmXkpX+vg1Q@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f681b0573e0f14b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9q_4UU6tz5MOtjwOhREdjrytoNI>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 17:07:25 -0000

On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie <paul@redbarn.org> wrote:

>
> Il 20 agosto 2018 alle 17.55 Ted Lemon<mellon@fugue.com>  ha
>>> scritto:
>>>
>>> I am entirely within my rights to use DoH whether the network
>>> operator likes it or not.
>>>
>>
> so, their network, but not their rules? when spammers used to tell me that
> sending spam wasn't illegal and i had to accept it, i blackholed them and
> said, my network, my rules. who has what rights, and why?


Paul, take a deep breath.   I'm paying for my network service.   My ISP
does not require me to use their DNS resolvers.   U.S. law does not require
me to use their DNS resolvers.   So yes, I am perfectly within my rights to
not use their DNS resolvers, but the reason is not "their network, my
rules."   It is that there's no rule against doing it.


> It is certainly true that in some cases, someone using DoH would be
>>> violating a network operator policy that is enforceable, or would
>>> be violating the law.   But that is by no means the most common
>>> case, and it does you no credit to pretend otherwise.
>>>
>>
> some references i've seen go by in this thread indicate that the DoH team
> wants its protocol to be unblockable, and hopes that RDNS DOH providers
> will co-locate their DOH endpoints with other valuable content, "so that
> network operators will think twice about blocking it."
>

I think the DoH team is not quite as cohesive as you think it is, but yes,
that is one implication of the use of DoH.  If you find it problematic,
then you need to get your end users to proxy all their HTTPS traffic
through your HTTPS proxy.   This will be really obvious to them, so you
won't be able to do it without their agreement.   This is by design.   This
situation has existed since HTTPS has existed—it's not something that DoH
invented.   You've always been able to use HTTPS to bypass firewalls; this
has good uses and bad.   Tough luck—see Figure One.  :)

if there are use cases beyond violating the law and violating network
> operator security policy, then they are obviously secondary, but do tell--
> what do you think those might be?
>

Preventing user behavior tracking seems like a pretty valid use case.


> i also block tor endpoints. because, my network, my rules. if it's going
> to be my network but mozilla's or cloudflare's rules, then this
> conversation is going to travel very differently, because i'll still be
> paying for it, but it won't be _my_ network any more. would that sit well
> with you? it wouldn't with me.


If you think that Mozilla isn't trustworthy, don't use Firefox.   It's all
about trust.   It's naive to think that you aren't going to have to trust
someone; thinking about trust models is no longer optional for network
operators.