Re: [DNSOP] [dns-privacy] 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: 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 ED3A61311AB for <dnsop@ietfa.amsl.com>; Mon, 11 Mar 2019 13:43:48 -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 cKjeKpBl2dnl for <dnsop@ietfa.amsl.com>; Mon, 11 Mar 2019 13:43:47 -0700 (PDT)
Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 560711311C9 for <dnsop@ietf.org>; Mon, 11 Mar 2019 13:43:43 -0700 (PDT)
Received: by mail-lj1-x241.google.com with SMTP id t13so350177lji.2 for <dnsop@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=NzZFlXVIDiZGlRVxLq0khJKWfuEgew3MYPIYZ5/c8ibp5qCWCCgQmZRsJNDOKUH0iZ h+fEb176LlBfyxkHRzGnJqNEsGxwmffZFS6/zmPY+sYV5M/UmAMVSQv3yqG2Shj6Qp8A ZQ9SbBlTUbDT/xDKxHVn2v3gu5fIZfuRUZPswnLOR+8EeC1x2xC4Fq8aoUVBjTKAtsMb Tzv0n1BxOZE0nyT0qi0jCOkKsiL06BhKeGY53Afj0r3CY6CbUUJXqluArflJJVHyBQoh sSGmRDMWFdL6dysr3ZJ+wWk8lTVtIzc0eVeKetI0C2wX/Fjc7oG9GlsuEIU9ZcW+Plvd z2CQ==
X-Gm-Message-State: APjAAAX+atiLLJbTLUYuQWYY2a32RHLFHCSBzNiu5n2jeTWX5sAuDkP7 eVl+5HisOvNe4IBby984mFIt6xtw1kQg6rWmcY5kGA==
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/dnsop/FuhP44tz4fgYmppDt4ZclsKho0E>
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 20:43:53 -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