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

Paul Vixie <paul@redbarn.org> Tue, 21 August 2018 02:41 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 5E309130E68 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 zAPgiIESx8mW for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:41:36 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98FC130DF6 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:41:36 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d] (unknown [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d]) (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 B6EF6892C6; Tue, 21 Aug 2018 02:41:36 +0000 (UTC)
Message-ID: <5B7B7BDE.9000704@redbarn.org>
Date: Mon, 20 Aug 2018 19:41:34 -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> <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> <5B7B0465.8060906@redbarn.org> <CAPt1N1m1c6k_Bn8GR4hMRD+A5iBq7bQsZ0CQqcoKJU1Y4nYvvQ@mail.gmail.com> <5B7B532B.6050708@redbarn.org> <CAPt1N1=QCFZHcuTm=aMMW0gCtKj2V6fHJ9ymveDSJfpLscJAxg@mail.gmail.com>
In-Reply-To: <CAPt1N1=QCFZHcuTm=aMMW0gCtKj2V6fHJ9ymveDSJfpLscJAxg@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/rQq1agHMDOu0hTpmC25xul5ZkWc>
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: Tue, 21 Aug 2018 02:41:39 -0000


Ted Lemon wrote:
> You're talking about devices over which you have no control.   So how
> does it make a difference where the attack vector is on the device?
> Why is DNS-over-HTTPS worse than entire-attack-vector-over-HTTPS?

i'm glad you asked. operating systems, web browsers, and endpoint 
security has a pretty good handle today on data plane attacks, even if 
delivered over https. they do not however have a handle on control plane 
attacks, such as can be delivered or administered via DNS.

http://www.circleid.com/posts/20100728_taking_back_the_dns/

if ubiquitous perimeter security policy bypass via https becomes the 
norm, then far more https will have to be intercepted or blocked than is 
done today. the DOH WG is playing chicken with network operators. i wish 
they could see down the road a bit further than they do.

-- 
P Vixie