Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal

Adam Roach <adam@nostrum.com> Tue, 10 July 2018 16:23 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58581130E4A; Tue, 10 Jul 2018 09:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 95QFJvmELtlu; Tue, 10 Jul 2018 09:23:29 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A743126CC7; Tue, 10 Jul 2018 09:23:29 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AGMtwP097444 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 11:22:57 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Joe Abley <jabley@hopcount.ca>
Cc: Paul Wouters <paul@nohats.ca>, driu@ietf.org, dnsop@ietf.org, DoH WG <doh@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>, Philip Homburg <pch-dnsop-3@u-1.phicoh.com>, HTTP Working Group <ietf-http-wg@w3.org>
References: <m1fcoe5-0000GuC@stereo.hq.phicoh.net> <alpine.LRH.2.21.1807101056140.5219@bofh.nohats.ca> <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca>
From: Adam Roach <adam@nostrum.com>
Message-ID: <e1675184-f0bc-670d-3db1-b99a9daf1657@nostrum.com>
Date: Tue, 10 Jul 2018 11:22:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/ykSwRnclGpAQgVGuG-cC3Z_6_Ls>
Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2018 16:23:32 -0000

On 7/10/18 10:30 AM, Joe Abley wrote:
> On Jul 10, 2018, at 16:09, Adam Roach <adam@nostrum.com> wrote:
>
>> [as an individual]
>>
>>> On 7/10/18 9:59 AM, Paul Wouters wrote:
>>> It seems more like an extension of the Public Suffix. Which domains can
>>> make claims about other domains.
>> Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have come up so far include: (a) If the record that is pushed to me is DNSSEC signed, is that sufficient to trust it? (b) If the record that is pushed to me is not DNS signed, but I'm using it in a context that requires TLS (e.g., HTTPS), and the thing that I connect to when I use the record can present a cert that proves its identity, is that okay?
> I think perhaps the people who have been having these conversations are not being ambitious enough.
>
> The pressures in the enterprise DNS market are overwhelmingly driven by the need to make web apps more reliable, load faster, and offer user-specific content. There are other reasons to want DNS tricks, but the customers that pay the big money are all concerned with HTTPS UX. Some of the decision points are in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX session initiation, but after that the HTTP layer has (can have) a far richer set of data about the user and is able to separate user-blocking decision-making from the flow of the UX which also affords extra time to make decisions without the user becoming frustrated.
>
> [To illustrate the architectural lunacy of the status quo, consider the data sets that are gathered through real-user-monitoring in browsers, served at the HTTP layer, that are subsequently used to steer DNS traffic used to retrieve resources back at the HTTP layer. There's a whole layer of derived datasets relating to the DNS there that are being generated by the web and used by the web, but with a tangy sandwich filler of DNS that is just overhead.]
>
> It seems like it would be nice then, after the UX-blocking elements are loaded and the user is already engaged, for subsequent lookups to be driven in HTTP and client-side scripting and to be presented to the stack as bare addresses rather than DNS names. That avoids the dependency on the DNS after initial page load altogether and leaves all the performance engineering decisions in the same place as the content decisions.

Basically, you're describing a solution space that could be realized as 
something like:

<img src="https://example.com/img/f.jpg" ip="192.0.2.1">

But this is really equivalent in just about every important way to 
sending the normal <img src="https://example.com/img/f.jpg"> along with 
a pushed DNS record that indicates that "example.com" resolves to 
"192.0.2.1" -- and this latter thing is (to my understanding, at least) 
in scope of the conversation that Patrick is proposing to have.

Note: I'm not saying anything about the trust issues that arise in 
either case, and I'm not trying to gloss over the need to perform a 
really careful analysis; I'm just saying that what you're suggesting is 
definitely equivalent to one of the implied eventual outcomes of what is 
being proposed.

/a