Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

Watson Ladd <watsonbladd@gmail.com> Sat, 06 April 2019 18:04 UTC

Return-Path: <watsonbladd@gmail.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 D827B120343; Sat, 6 Apr 2019 11:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 jkB8Fx75oGST; Sat, 6 Apr 2019 11:04:15 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 3AB9D120088; Sat, 6 Apr 2019 11:04:15 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id p14so7844208ljg.5; Sat, 06 Apr 2019 11:04:15 -0700 (PDT)
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:content-transfer-encoding; bh=b6Euf47XWEtl5GAq60AgnEDxFTNZPhVd490lCln0jUk=; b=LN+T1zbNQuAl0GqjuPEWx/NQaEO/PBPSp0VbT7NddHlYaAZ++gR9P4Dt34IuVwvDQm ufKuE7zwXtVHOm5jcuN9i88rLLIgY1yvoFmgFV4nx4IWyJZmlX/y4V0MLetXneTcU5LT JxFqOuhAKSWNT1UQ8Cv0ote4MdeUUuzxyvb4YLYhhb88wQNuRxcjzRTmyZcB/22CYsap yfgdY0u5hHUCWSwfo9DWl5xTmsIfnbnZfOkDcRvNni6xF+/zRPc7iefMl/dprQTD8riE CT/IVOtn4pWmyszmIdIMvYRndiY26KwIRZBgwr3QsYFSJ05zMTAfmVGnO40cfbtS34Or YBRg==
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:content-transfer-encoding; bh=b6Euf47XWEtl5GAq60AgnEDxFTNZPhVd490lCln0jUk=; b=bJ+ovIvSRSbJvIQ3b8TFnd+EMVjCvCPvuKyP+pCKtPuHfF7DsuFXayXoaKMmJ5f0xZ mw3mkXcpkVIzK/lPU+nGarePwyzAJUOJKSOYRiS12ZTdO2WUOi7oUbIRxcWgypipfypV fEunB0BnY0AzhnmE2ThNVGROlarc7wLK4sgyAw4nUe4K/gTdJ/R/4Y9fNn0TDljl9hOU FRgjVwI/CFE/+ts1gnuhPSo7XkuLKDI1Ov32ZcdQkN8p1hCDqA8Gp8FGtlgYcLebxmCM 7S9UQnlngXHkJ7XWWWVI528zntUy7ecxGkkailaCKRmm/h0JWb+JAOcVvW4LJAqkYwa7 vmdA==
X-Gm-Message-State: APjAAAUa4B0jlu8fjr1YNnl0gidydSS3dgRF1xrNQgADE4ei5YDr1xfk 2Eb8w9OpntZ4ToeUPO6zORxa0wENMvleo7wHIgj3jQ==
X-Google-Smtp-Source: APXvYqz5TA+Qyj1nTKlFR+ZikOUV6gnbg2vpP8wbaIG+2T4ep0esVRAPO9h+6r5tKNP4REcvQhBaDnOF+iBEG0hltks=
X-Received: by 2002:a2e:b016:: with SMTP id y22mr11162525ljk.133.1554573853392; Sat, 06 Apr 2019 11:04:13 -0700 (PDT)
MIME-Version: 1.0
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <eea64b30-aad0-a030-5360-1b1484f1d0e3@huitema.net> <CAPsNn2WhjHSEHJUEL8GB6X0d24fkajgPnY4YgkOQbXjyxb5q8Q@mail.gmail.com> <CACfw2hj07TDCxK9bm0T=JguKyuCEfW2zb_yRJnewjOYL4oxdjA@mail.gmail.com>
In-Reply-To: <CACfw2hj07TDCxK9bm0T=JguKyuCEfW2zb_yRJnewjOYL4oxdjA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 06 Apr 2019 11:04:01 -0700
Message-ID: <CACsn0cmk7NbF+ti0dU7Fp0PK8Gt4P5knC5hrHVLDY59-jaYYzA@mail.gmail.com>
To: william manning <chinese.apricot@gmail.com>
Cc: nalini elkins <nalini.elkins@e-dco.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, doh@ietf.org, dnsop <dnsop@ietf.org>, Christian Huitema <huitema@huitema.net>, dns-privacy@ietf.org, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, "Ackermann, Michael" <mackermann@bcbsm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/G3IfaQBqWNBQDio-i6ymbU4S8Q8>
Subject: Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 06 Apr 2019 18:04:19 -0000

On Fri, Apr 5, 2019 at 9:45 AM william manning
<chinese.apricot@gmail.com> wrote:
>
> Every now and then, Paul Vixie and I are in complete harmony.  In my current slot, we are one of thousands of entities that are being held accountable to a series of regulatory requirements that have significant fiscal impacts on the exfiltration of private/patient data.  We are starting to focus on three distinct areas to reduce the impact that DOH presents to our security posture.  1) In contractual/proccurement language.  We have some "Must have" items and now we will have "Must not" items.  2) There are at least two technical options for tracking/blocking DOH which are being turned into turnkey options to "swat" this covert C&C channel.  3) Aggressive Browser Hygiene.
>
> This genie has not signed BAA or supplier agreement with us and we will not allow it to dictate our business processes or affect our liability without the DOH enabler shouldering fiscal and legal exposure when DOH is shown to be the culprit in exposure of private data.  I can't see how DOH is going to pass GDRP muster inside the EU either, but that is for others to debate.  I have told my GDRP affected counterparts about the privacy risks with DOH deployment.

You know you can just turn it off the same way you configure your
devices on your network. I also don't understand the GDRP issue you
raise: surely all DNS services have the same problems.

I'm more than happy to show you how to click the checkbox to turn it
off in Firefox. In fact there is a checkbox you need to click to turn
it on, and you can customize it at will. (I literally just checked)

> as usual, YMMV.
>
> /William Manning
>
> On Sun, Mar 10, 2019 at 8:26 PM nalini elkins <nalini.elkins@e-dco.com> wrote:
>>
>>  > Similarly, putting DNS in user space allows for immediate adoption of DNSSEC and privacy enhancements, even when the operating system or the local network does not support them
>>
>> At enterprises (banks, insurance, etc) on their internal networks, people run their own DNS servers which may resolve for both internal and external sites.
>>
>> We were recently talking to a Fortune 50 company in the United States about what might happen you install a version of the browser which uses DNS-over-HTTPS automatically.  (Clearly, this applies to any variant.)
>>
>> The questions that the Fortune 50 company architect asked were something like this:
>>
>> 1. You mean that DNS could be resolved outside my enterprise?
>>
>> 2. So whoever that is that resolves my DNS sees the pattern and frequency of what sites my company goes to?
>>
>> 3. How do I change this?
>>
>> I look forward to a discussion on this issue..    There will be at least one enterprise present in Prague to speak for themselves.  I will see if I can get others to participate remotely.
>>
>> It would be good to also discuss how to warn enterprises that this is about to happen.   I wonder if an announcement via CERT or another group may be appropriate.
>>
>> Thanks,
>> Nalini
>>
>> On Mon, Mar 11, 2019 at 6:36 AM Christian Huitema <huitema@huitema.net> wrote:
>>>
>>>
>>> On 3/10/2019 4:07 PM, Vittorio Bertola wrote:
>>> > Honestly, I understood it differently - at this point in time they are
>>> > doing tests on whether their resolver performs better or worse than
>>> > the system's one, but their announced model is that Firefox will adopt
>>> > a DoH resolver (though it's unclear how it will be chosen) and it will
>>> > just use that one. But if people from Mozilla could make a clearer
>>> > announcement on what their plans currently are, that would be good.
>>> > Still, most of the issues arise whenever an application, for whatever
>>> > reason and under any mechanism, starts to use one or more resolvers
>>> > different than the one set up in the operating system: even if it used
>>> > more than one, you would still get many of the issues listed in the
>>> > document (though, if it used more than one at the same time, I think
>>> > you'd actually also get some new specific issues, so we'd need to add
>>> > a discussion of this possibility).
>>>
>>>
>>> Your view of operating systems and applications is firmly rooted in
>>> history, which is another way to say in the past. The evolution in the
>>> past years points to a systematic deconstruction of that relation, with
>>> for example virtual machine, containers, or the trend to move network
>>> stacks out of the operating system and into the application. This is
>>> pretty obvious for security stacks, but it is also becoming very clear
>>> with QUIC and transport stacks. There are two big drivers: portability,
>>> and rapid adoption of innovation. These two drivers apply to DNS just
>>> like they apply to transport.
>>>
>>> Putting QUIC in application space allows for immediate provision of
>>> innovations like 0-RTT, head-of-queue blocking mitigation, or the better
>>> crypto of TLS 1.3. Similarly, putting DNS in user space allows for
>>> immediate adoption of DNSSEC and privacy enhancements, even when the
>>> operating system or the local network does not support them. That genie
>>> is not going back in the bottle any time soon.
>>>
>>> -- Christian Huitema
>>>
>>>
>>> _______________________________________________
>>> dns-privacy mailing list
>>> dns-privacy@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>>
>>
>> --
>> Thanks,
>> Nalini Elkins
>> President
>> Enterprise Data Center Operators
>> www.e-dco.com
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.