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

nalini elkins <nalini.elkins@e-dco.com> Mon, 11 March 2019 03:25 UTC

Return-Path: <nalini.elkins@e-dco.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 F21A2130EB9 for <dnsop@ietfa.amsl.com>; Sun, 10 Mar 2019 20:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-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 OxWZ709oi0ep for <dnsop@ietfa.amsl.com>; Sun, 10 Mar 2019 20:25:26 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 971BB130EBF for <dnsop@ietf.org>; Sun, 10 Mar 2019 20:25:23 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id d24so2674079ljc.12 for <dnsop@ietf.org>; Sun, 10 Mar 2019 20:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9IKiD6CpLovUwBErlWk6G8yLEAww3/X1Ecffurzt2HU=; b=MbxykKbMAEDOYHHkG2LFQDx5HDmWE74g9G4TOfEKvgoGRzXuOHh37yvRzem+0WhMA3 hhsUDmfDdQq7og/1fnI5uontcISYERr+Q5cBMRaPavjAOHbzZocsurHwmw8MARZNBYqR ZuiF/8Lavs6fxd2sucTjNcoyvMCDhEcA68QDPFJW7e8Z2Xm1SEPujhG8Uh7ZS2MnAlBb mxMXfUtGyXQQjr/YABWZ1f2TUId1Bz1BArQOZPAtc1v9yQX1j747jv5SgLgEcBwUMQNY clT+KCAADxorDXZugYkDD4MyVv2YSJfiGtJH5tYqdMTLnlkjuvJJvlyFKNYRI9lMQkk/ 9z6g==
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=9IKiD6CpLovUwBErlWk6G8yLEAww3/X1Ecffurzt2HU=; b=B3Ol3DoNDNJur7d8F9CGvgz7H67yUQBHtIRFKFd4Gc7e+FyH/I95twKv/SUwEfZ2rg L/ST0WZl1gcvjkdtIMZlxLlXrg7fyPI3106Rkrdfst2aMhqDSeFCgDPYbf3yu5t2yKyS vyzzh5IuBTxEcaltnT8T7JxvEhenKbptQaA9aEG/ycNlfaeGzhQlWgC7mpKyaBPe+mny TKGCH/ELisZzA4mi2Wki7O5a6fw38YFv68ySYiR+zIlCSaY/ggUcxivTYnugWW2EIhuk UVjD5Sp+JkdSVh2qaR3t1MKmF4z5QWeh0W/9I3efcSg7RrbXOlg2F3ikcDmaN6EtbDyD eMbg==
X-Gm-Message-State: APjAAAVlksMUIDXl3AVPRFyrVhVp8fZS8WXlRhoX6ObHhnRb+9Z7tc2t y1V2YlBxtJdwc5083GCSzee3W3fOH2Xujj935I1wQA==
X-Google-Smtp-Source: APXvYqwiZ1APh+hymPH6C28PgZnmlajXgW6Bd5evGlKv9zI/6bXwF0iqHKJljei5pga7Ab8+tK4VaHfp6f0o1CvUmVo=
X-Received: by 2002:a2e:9b15:: with SMTP id u21mr15233154lji.82.1552274721524; Sun, 10 Mar 2019 20:25:21 -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>
In-Reply-To: <eea64b30-aad0-a030-5360-1b1484f1d0e3@huitema.net>
From: nalini elkins <nalini.elkins@e-dco.com>
Date: Mon, 11 Mar 2019 08:55:18 +0530
Message-ID: <CAPsNn2WhjHSEHJUEL8GB6X0d24fkajgPnY4YgkOQbXjyxb5q8Q@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, dns-privacy@ietf.org, doh@ietf.org, dnsop@ietf.org, "Ackermann, Michael" <mackermann@bcbsm.com>
Content-Type: multipart/alternative; boundary="0000000000005ee33e0583c91fa1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5g79AydXy1axkM-0t_JqLfxFtBQ>
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: Mon, 11 Mar 2019 03:25:28 -0000

 > 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