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

Adam Roach <adam@nostrum.com> Tue, 10 July 2018 17:06 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 4C3E0131142; Tue, 10 Jul 2018 10:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level:
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 BbMY-Hgud_Ve; Tue, 10 Jul 2018 10:06:13 -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 89A6C13113E; Tue, 10 Jul 2018 10:06:13 -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 w6AH5jek004872 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:05:46 -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: Ted Lemon <mellon@fugue.com>, Joe Abley <jabley@hopcount.ca>
Cc: DoH WG <doh@ietf.org>, driu@ietf.org, dnsop WG <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>, 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> <e1675184-f0bc-670d-3db1-b99a9daf1657@nostrum.com> <CAJhMdTOZtOpF_aK-ZzP0DfkDMcAtTKFLdSpKkrSPvP1cOgnOjQ@mail.gmail.com> <CAPt1N1=Xky1MjmbzdnR2zxcVbD3mz0O3Qo_uEVK96uMLUrwu8g@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com>
Date: Tue, 10 Jul 2018 12:05:45 -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: <CAPt1N1=Xky1MjmbzdnR2zxcVbD3mz0O3Qo_uEVK96uMLUrwu8g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------BCF78CA0739BD930ABF88DE6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/9SyOa_GW5T5ihuFSuspaRCYk_2s>
Subject: Re: [Driu] [DNSOP] [Doh] 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 17:06:16 -0000

On 7/10/18 11:41 AM, Ted Lemon wrote:
> On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jabley@hopcount.ca 
> <mailto:jabley@hopcount.ca>> wrote:
>
>     > But this is really equivalent in just about every important way to sending the normal <img
>     src="https://example.com/img/f.jpg
>     <https://example.com/img/f.jpg>"> along with a pushed DNS record
>     that indicates that "example.com <http://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.
>
>     My question is why you would involve the DNS at all if all the
>     performance-based resolution decisions can be made without it. You're
>     just adding cost and complexity without benefit
>
>
> The ip= modifier would be a great way to arrange for something to look 
> like it came from a different source than its actual source.   I'm 
> sure there's an attack surface in there somewhere.


Keeping in mind that the certificate provided by whatever machine you 
reached would necessarily have to match the URL's origin, this is very 
much one of the questions that is being asked: is there?

/a