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

Tom Pusateri <pusateri@bangj.com> Tue, 21 August 2018 16:47 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 071E5130F0D for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 09:47:25 -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=unavailable 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 MFEtrUl6GdIu for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 09:47:22 -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 6507B130E4B for <dnsop@ietf.org>; Tue, 21 Aug 2018 09:47:22 -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 5086E232F; Tue, 21 Aug 2018 12:43:18 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <35BFAE4B-D68E-4D0A-BD1A-1D994100A3B6@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0ABC468-3161-43E0-BCCB-1499BA105EA1"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 21 Aug 2018 12:47:25 -0400
In-Reply-To: <CAC=TB10bYP2UPO9RPs6Tjm9OO_PTUcoQp=VNMLaBjb+mMoVxyw@mail.gmail.com>
Cc: =?utf-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>, dnsop <dnsop@ietf.org>
To: =?utf-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa=40cloudflare.com@dmarc.ietf.org>
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> <252FC541-311D-4892-9F0D-B0D7BB2EEC2A@bangj.com> <7050b6ed-6e99-314b-153a-f969288191e7@nic.cz> <CAC=TB10bYP2UPO9RPs6Tjm9OO_PTUcoQp=VNMLaBjb+mMoVxyw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/egGEoMx2hM73_LRdVukhqI6q9FU>
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 16:47:25 -0000


> On Aug 21, 2018, at 3:30 AM, Marek Vavruša <mvavrusa=40cloudflare.com@dmarc.ietf.org> wrote:
> 
> On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <petr.spacek@nic.cz <mailto:petr.spacek@nic.cz>> wrote:
>> On 21.8.2018 04:38, Tom Pusateri wrote:
>>> 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.
>> 
>> Could you elaborate how DOH helps here? I can't see it now.
>> 
>> We already have RFC 7901 (Chain Query requests in DNS) which allows
>> resolvers to get all RRs required for DNSSEC validation in one round
>> trip even over "classic" DNS.
>> 
>> This haven't been implemented because up to know browser vendors have
>> not been interested in DNSSEC which consequently lead us (resolver
>> vendors) to ignore complex RFC with no demand.
>> 
>>> From my point of view DOH does not change anything in this regard,
>> complexity on stub & resolver side is the same no matter what transport
>> is used.
>> 
>> What am I missing? How does DOH help with this complexity when compared
>> to classical DNS?
> 
> I think Tom is referring to the h/2 push semantics. The resolver can
> push the trust chain records
> ahead of time, so the forwarder will already have them in cache when
> revalidating the final answer.

Yes, plus the fact that the web/DoH server already knows all of the questions you might ask because it just fed you a page of content with links.

The Chain Query Requests in DNS (RFC 7901) are awesome for the stub resolver. But the web/DoH server has more knowledge that the stub doesn’t have yet and so it can benefit from this knowledge in a way that the stub resolver can’t.

Tom