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

Tom Pusateri <pusateri@bangj.com> Tue, 21 August 2018 02:38 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 B1DD8130E7F for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:38:48 -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 lpfi7GXpWxFI for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:38:46 -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 3410F130EB5 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:38:46 -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 C5BC220DB; Mon, 20 Aug 2018 22:34:45 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <252FC541-311D-4892-9F0D-B0D7BB2EEC2A@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F75B3CB-FB1F-4389-A276-9BCE0780D9F2"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 20 Aug 2018 22:38:44 -0400
In-Reply-To: <DA13BC82-2308-4B28-B86B-A52D678A1BFD@bangj.com>
Cc: Paul Ebersman <list-dnsop@dragon.net>, Paul Vixie <paul@redbarn.org>, 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> <DA13BC82-2308-4B28-B86B-A52D678A1BFD@bangj.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vIRfq7QCXJHp7QmPtLDOOUPZ4Nc>
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:39:01 -0000

Come to think of it, DNSSEC validation in the stub resolver or browser is really a place DoH could shine. Instead of all the round trips required for validating up (down) the chain, the webserver could package up all those validated records and push them so the client/stub could do the validation quickly for all of the links in a page in an order that the user is most likely to need based on previous statistics and scrolling position.

Tom

> On Aug 20, 2018, at 10:31 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> 
> 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 <mailto: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>
>> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop