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

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

Return-Path: <nalini.elkins@e-dco.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB9B1311A0 for <dns-privacy@ietfa.amsl.com>; Mon, 11 Mar 2019 13:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, NORMAL_HTTP_TO_IP=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 Cihebq40DGeu for <dns-privacy@ietfa.amsl.com>; Mon, 11 Mar 2019 13:43:43 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 55DF11311C3 for <dns-privacy@ietf.org>; Mon, 11 Mar 2019 13:43:43 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id x13so333237ljj.5 for <dns-privacy@ietf.org>; Mon, 11 Mar 2019 13:43:43 -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=xt4Iw//cVRXManG4BIdxrjJe1wpkbP7taIrKwMF0WRk=; b=mkbBsGSNYJqvcZrqNdMVlNrLI2dLtg3Esky9pRICaeAdioN0atKG0rg8wzBpXHwpre wqZqNhZICxt0mG9bxy+lC/kv3D/iFgtf6Zgz287HpzsCEd8W0zAGquYAn7G2eVAauS4+ HAux/2LTIHOinRrjaA0Xys/+P+NSHtYmFNjA/xf3aF65T4PvXskIsGYf8a7dlfWXMe2r Ptc2W7jTLK1eUcb8op7ck98r1JVKzc4Xjf7H13d69zdF7Nzc9lGlHqmZInUDZuvIAfkQ inEeOggn25BK+bfkyuHBnPTZLkZarPEB4vrYqPEsAFClclytYZe1wbFkfqzgzcOnDblh +SOw==
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=xt4Iw//cVRXManG4BIdxrjJe1wpkbP7taIrKwMF0WRk=; b=LYNVhLUhazuAYoYyoA0g6EKMp/xyxu73bXPhKLCIkgVjxlxyQhsjw2FfMyhHRFNKvN NyxJ5WW/ypMrSA2RiRX59s8kufrP2qXjPlF5sUHVS2X3XREkXL1P7q21CKIrs0IcULIp wlnQ029QqXPxu29/4J3TA/Y5/DhhJaBeBXLJqJhO9+IGtQMxrMx83Hzb/99DBjWdoNnx 8txYI9+0N2Hjo55rWKSf7v0gL6HIrZh9Qwlzur07K/b6gB2RUoUgYEhYIa8Aakly3iG1 cpKIk7qotRp9++UQNq0IM3DT+oZZcRR0QSx7CTTCDdUY0yU0eeSV9ULE/chKMGyOwuEs 0mTQ==
X-Gm-Message-State: APjAAAXXcCL3jSirDtA41Xr4bzn7s5EjQkddw/yI4dRB0r12bGtRoNAb EsSm53GMS7TjJTMvX4KKNPAge2xMfVV3yTR3ULjjnQ==
X-Google-Smtp-Source: APXvYqwSlIGicz6r+XCYz1p03I/bdXCAf4G1RV0C/pVMDx5gMOKpbmbk28Pxem/iuYFi0P/x1hz10jHCR1Nwuq+kR3s=
X-Received: by 2002:a2e:a28f:: with SMTP id k15mr17962255lja.160.1552337021307; Mon, 11 Mar 2019 13:43:41 -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> <e62efaf3-4a35-4a52-5ed4-dee2e7fafe72@huitema.net> <69f989ba-0939-b917-b586-9e3af3fb8b74@redbarn.org> <CAPsNn2XNCzgAdfJtxBVboAe+d6sbCiV2fZv9185wm+HN+3zRdg@mail.gmail.com> <BYAPR16MB279065EE519680E7FC9A637CEA480@BYAPR16MB2790.namprd16.prod.outlook.com> <CAPsNn2Up1AtJJCdmu_9NC4jfzc-8dtE+QjUzRxMBUwaN44gvOg@mail.gmail.com> <76386691-c1aa-c48a-9b0d-67eb36a08a4f@redbarn.org>
In-Reply-To: <76386691-c1aa-c48a-9b0d-67eb36a08a4f@redbarn.org>
From: nalini elkins <nalini.elkins@e-dco.com>
Date: Tue, 12 Mar 2019 02:13:30 +0530
Message-ID: <CAPsNn2VAgLDW++kb=Csfczp4oydqa4sY-dKWw7P7qTwj=MfxdQ@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Christian Huitema <huitema@huitema.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, "Ackermann, Michael" <mackermann@bcbsm.com>
Content-Type: multipart/alternative; boundary="000000000000ba2bff0583d7a0f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/UWu8iFQ06Y9zOcIMAyTeBl5Ac6g>
Subject: Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 20:43:52 -0000

>i wonder if everyone here knows that TLS 1.3 and encrypted headers is
>going to push a SOCKS agenda onto enterprises that had not previously
>needed one

I have, ahem, some familiarity with the enterprises and TLS1.3 issue.
(These
past few years have aged me terribly!)  I frankly feel that we have at the
IETF
a problem with the how we do conflict resolution and the process of
consensus
itself.  In fact, I co-authored a draft on this topic:

https://tools.ietf.org/html/draft-elkschul-conflict-problem-00

I feel that until we fix these fundamental issues, we will find ourselves
in this
place again and again.   The next time will be with QUIC (as Paul points out
in his mention of encrypted headers).  I actually have some suggestions as
to how we might better work with each other.  But, I do not want to
sidetrack
into a much larger issue.

At a minimum, I think that some relatively neutral arbiter, say CERT, might
provide an after the fact impact assessment that certain changes such as
DoH and TLS1.3 will have on enterprises, the home user, and so on.   Of
course, it would be better if such a neutral assessment were done BEFORE
the draft becomes final.

This is similar to what is done in California on ballot initiatives.  When
we get our
voting pamphlet, it tells us for each issue, what impact a pro or con vote
will have
on various aspects such as increased taxes, and so forth.

Nalini

On Mon, Mar 11, 2019 at 11:42 PM Paul Vixie <paul@redbarn.org> wrote:

>
>
> nalini elkins wrote on 2019-03-11 10:26:
> > Tiru,
> >
> > Thanks for your comments.
> >
> >  > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to push a SOCKS agenda onto enterprises that had not previously
> needed one, and that simply blocking every external endpoint known or
> tested to support DoH will be the cheaper alternative, even if that
> makes millions of other endpoints at google, cloudflare, cisco, and ibm
> unreachable as a side effect?
>
> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i
> blocked already (before DoH) so that's not a problem. but if google
> decides to support DoH on the same IP addresses and port numbers that
> are used for some API or web service i depend on, that web service is
> going to be either blocked, or forced to go through SOCKS. this will add
> considerable cost to my network policy. (by design.)
>
> --
> P Vixie
>
>

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com