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

Paul Vixie <paul@redbarn.org> Mon, 20 August 2018 18:11 UTC

Return-Path: <paul@redbarn.org>
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 3879A130E86 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 11:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JxcxBBEqgob2 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 11:11:51 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C59130E4A for <dnsop@ietf.org>; Mon, 20 Aug 2018 11:11:50 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62] (unknown [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 05918892C6; Mon, 20 Aug 2018 18:11:51 +0000 (UTC)
Message-ID: <5B7B0465.8060906@redbarn.org>
Date: Mon, 20 Aug 2018 11:11:49 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: Joe Abley <jabley@hopcount.ca>, dnsop WG <dnsop@ietf.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@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> <CAPt1N1=ad9MyZmHncTfdDV9pPim9cDC=boAFD9UxmXkpX+vg1Q@mail.gmail.com> <5B7B001A.5000907@redbarn.org> <CAPt1N1mfBz3E96ZuLAbBFYzhrwmg8ukrgsabC-duCOj1-rKK4A@mail.gmail.com>
In-Reply-To: <CAPt1N1mfBz3E96ZuLAbBFYzhrwmg8ukrgsabC-duCOj1-rKK4A@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ExSOSjT8wvYflKQ6_o2WBD7d9xk>
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 18:11:52 -0000


Ted Lemon wrote:
...
> I think HTTPS was pretty hostile to local network policy.   Indeed,
> there was a big argument about that in the TLS working group over the
> past few IETFs.   If you don't want people to use DoH, there's an easy
> solution, which you already need to use regardless: you have to MiTM
> their HTTTPS traffic.   If you don't agree that you have to MiTM their
> HTTPS traffic to achieve what you want, then I think we are not arguing
> about the same thing.

it used to be occasionally necessary. with DOH it will be universally 
nec'y. this will add complexity (so, cost and error rate) and increase 
surveillance. the DOH people should be told not to proceed to draft 
standard until their design accommodates the needs of network operators.

-- 
P Vixie