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

Paul Vixie <paul@redbarn.org> Tue, 21 August 2018 19:23 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 D4386130E78 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 12:23:34 -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, 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 u5XbYyegoCus for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 12:23:33 -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 4A953130DF7 for <dnsop@ietf.org>; Tue, 21 Aug 2018 12:23:33 -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 1DDF6892C6; Tue, 21 Aug 2018 19:23:33 +0000 (UTC)
Message-ID: <5B7C66B2.70408@redbarn.org>
Date: Tue, 21 Aug 2018 12:23:30 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Tom Pusateri <pusateri@bangj.com>
CC: Marek Vavruša <mvavrusa=40cloudflare.com@dmarc.ietf.org>, dnsop <dnsop@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> <35BFAE4B-D68E-4D0A-BD1A-1D994100A3B6@bangj.com>
In-Reply-To: <35BFAE4B-D68E-4D0A-BD1A-1D994100A3B6@bangj.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/G3JH3vnqEAfPpNDMc4gEvo9FpQQ>
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 19:23:35 -0000


Tom Pusateri wrote:
...
> 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.

for this to matter, the user will either have to visit a very large 
number of completely unrelated destinations, or will have to visit the 
same site or site-cluster many times. i consider the former unlikely, 
and have therefore limited my thinking to the latter.

in the case where someone is visiting the same site or site-cluster many 
times, the cost of fetching the necessary crypto-chain materials will 
only be borne once, or at worst very infrequently, due to caching.

this means that the difference between having the crypto-chain pushed to 
you in advance by someone who can predict where you're about to go 
because they're also sending you content with those references, will be 
so rare as to be non-impacting.

in addition, DoH is not connected to web service in any necessary way. 
the DoH channel will be to a DoH provider such as CF. while there's a 
good chance in today's internet that you'll also be fetching content 
from CF, there are in fact other CDN's and many non-CDN content hosts. 
if you are talking to any content host other than CF, then the CF DoH 
service will have no knowledge of what to push toward you.

in further addition, even in the case where you have a persistent CF DoH 
connection open, it may not be easy for CF to share enough 
connection-state between its DoH and other-content servers so that the 
one will be able to push crypto-chain information to you in support of 
the other.

in short, i don't think DoH can usefully optimize by pushing.

-- 
P Vixie