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

Ted Lemon <mellon@fugue.com> Tue, 10 July 2018 17:10 UTC

Return-Path: <mellon@fugue.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 9B446131179 for <driu@ietfa.amsl.com>; Tue, 10 Jul 2018 10:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 3RRkZL1Dubdy for <driu@ietfa.amsl.com>; Tue, 10 Jul 2018 10:10:29 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 5E464131169 for <driu@ietf.org>; Tue, 10 Jul 2018 10:10:29 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id v71-v6so21834081itb.3 for <driu@ietf.org>; Tue, 10 Jul 2018 10:10:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RtdV3HVCVufDVCnq++2dHOceaWsMe1UFGNtOa00Lwjo=; b=jR5z/QXcPGTwzEoYnfKa8G6/yrPQ+SSA3mef+XV+mpfpnx8PSd1j0fxQjDtQc/jybT 9RskP7jjfTegFE4dPnmLiABjEqQndSfw0+NORmuU+OkeR3/49MdR9KGw2Rhfg7ZMjtpU TU7QDL1AVyxLJDiN2GTChqHM8M/TGfAu7K+ye18A983a7uZ93xg3UWATCxrZI6ikbSbi VCLczQjCT7/AeqUQYt8Tb7Hd8CTkmTINACM1r2l8zoLEHLHS3DcuErTJN1t73vjfw5pv F/72XkpISorNw9o/150/dsw5ef0wZHxz1yJ3rly8NxRf/7wir0bOiGURzfuB+eqyEurX +1qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RtdV3HVCVufDVCnq++2dHOceaWsMe1UFGNtOa00Lwjo=; b=EoQJYrcIRaBKY1hk1+T44+KkUxgOncpG1/611rPu7t09ZejQhfK5h/+zC3hUktGMsf qk9TZgRtIwVJDihKRNpsc7+PYCVjAFfKd/0tmNXlj6uWCdgA5AUvft55D5CngL0mhcxc bm80pGdB+rsxkt06HtEJ7ESpllS2A9+PZ2UkamO3+DjVzrEaOHm05Y5jGWMPI+1hZ1V6 YFQO7aXWaBsGJ8IPSviaIMYkU3rje+syn36Shv/tVnGcGfyWWaVwSxf/urcwIDul0sra N0oZwqqZ/6V8IY2id7Mlg+KIt6MkNDAu8laq8MuCO6R4R5MmqxLw0Eji3rTMoRUSdwhe Gz0Q==
X-Gm-Message-State: APt69E3PRVeRoehrLBt5cWhksgR+i3TXvXkwAF6+F88TfOlH5f26qQku 1INuSgVl/6wHj3cjA2zzYNspBU77lAOoziDbNEJaJw==
X-Google-Smtp-Source: AAOMgpdDByd6uGTOUoX5d/reHjvZIEsm+EVeQMfGHbScTDQ/wEgRolu9bVFgmCFJMCLSfsIhbM+6unYR0t3u30ScJxs=
X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr20659576jad.38.1531242628657; Tue, 10 Jul 2018 10:10:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:09:47 -0700 (PDT)
In-Reply-To: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com>
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> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 10 Jul 2018 13:09:47 -0400
Message-ID: <CAPt1N1mRq4MFbrhos=jvv8pmNBO4S9r_Fne_A6=fzhiQdrLjww@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Joe Abley <jabley@hopcount.ca>, 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>
Content-Type: multipart/alternative; boundary="000000000000f248aa0570a83488"
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/AOyoLM7wC_QkTXnX6jWKKSv-DSs>
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:10:33 -0000

I'm not suggesting that the attack surfaces couldn't be closed, and that
does seem like it would be sufficient to close them.   However, we've been
burned by implementations not getting details like this right in the past,
so that's why I brought it up.

On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <adam@nostrum.com> wrote:

> On 7/10/18 11:41 AM, Ted Lemon wrote:
>
> On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <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"> 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.
>>
>> 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
>