IETF Logo Mail Archive

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

Tom Pusateri <pusateri@bangj.com> Tue, 21 August 2018 02:31 UTC

Return-Path: <pusateri@bangj.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 E2D45130E68 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:31:53 -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, HTML_MESSAGE=0.001, 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 6ZCqygDW1sCV for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:31:50 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D170130E7B for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:31:50 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E440220D1; Mon, 20 Aug 2018 22:27:49 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <DA13BC82-2308-4B28-B86B-A52D678A1BFD@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0C29926-0347-4351-9D8D-5608595269F7"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 20 Aug 2018 22:31:48 -0400
In-Reply-To: <CAPt1N1k=xnSiF_DQXz6OS=MdRe5YHbL0CgXHAUdgWgH4vdBDMA@mail.gmail.com>
Cc: Paul Vixie <paul@redbarn.org>, Paul Ebersman <list-dnsop@dragon.net>, dnsop <dnsop@ietf.org>
To: Ted Lemon <mellon@fugue.com>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk> <23C2BA0B-B4A7-49F2-9FFD-90B90E2928B5@bangj.com> <56B7EA81-A840-4320-BDD0-781E9D999904@vpnc.org> <B5CCB149-BEE2-46D4-BF3C-C32D5BCA3EA3@bangj.com> <20180821014030.C2678AD6354@fafnir.remote.dragon.net> <922DCF48-BA8A-42B8-99BA-2B367D981568@bangj.com> <5B7B7718.7090301@redbarn.org> <EEEB9610-FB85-475D-ACF4-8F07E9884D8D@bangj.com> <CAPt1N1k=xnSiF_DQXz6OS=MdRe5YHbL0CgXHAUdgWgH4vdBDMA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GnFlXKMWutG-lVUs8Lgs3UrL-es>
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:32:07 -0000

Sure. My point was that there could be legitimate uses of DoH.

You have to move DNSSEC validation from the resolver to the client in order to really validate the answers if you can’t trust the resolver.

Tom


> On Aug 20, 2018, at 10:28 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Of course, the question is, how does the consumer of that data decide what is okay and what's not?   We can't just say that the server has to behave correctly: someone has to enforce it.
> 
> On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
> 
> 
> > On Aug 20, 2018, at 10:21 PM, Paul Vixie <paul@redbarn.org <mailto:paul@redbarn.org>> wrote:
> > 
> > 
> > 
> > Tom Pusateri wrote:
> >> ... I don’t know if it’s generally accepted that DoH will replace
> >> UDP/53 or DoT in the stub resolver or DoH will just end up in the
> >> browsers as a way to speed up web pages. But if DoH stays in the
> >> browser and DoT is tried and used on all DNS servers, there’s not a
> >> problem to solve.
> > 
> > if DOH is widely used by criminals, botnets, and malware to bypass perimeter security policy, then there will be a big problem and we will be solving it for many years to come, even if the browser is the only thing using it. browsers are where most modern vulns have occurred, and i expect that trend to accelerate. "because that's where the money was.”
> 
> I can see good use cases and bad ones.
> 
> If web servers did DNSSEC validation and only served addresses for names that were validated, I wouldn’t have a problem with that at all.
> 
> If web servers only served addresses for names within the domain of the web server, I wouldn’t have a problem with that either.
> 
> if they start serving non DNSSEC validated addresses for names outside their domain, I think they’re overreaching.
> 
> Tom
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
>

v2.27.6 | Report a Bug | By Email | System Status