[Doh] Talking to my resolver

"Martin Thomson" <mt@lowentropy.net> Sun, 17 March 2019 22:03 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525051311FB for <doh@ietfa.amsl.com>; Sun, 17 Mar 2019 15:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=JPqSr4JB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ra2b9H1s
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 ikJs2hYKgykC for <doh@ietfa.amsl.com>; Sun, 17 Mar 2019 15:03:30 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395F91279A3 for <doh@ietf.org>; Sun, 17 Mar 2019 15:03:30 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 59BE120B63 for <doh@ietf.org>; Sun, 17 Mar 2019 18:03:29 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 17 Mar 2019 18:03:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=OEUk/BJ9UdMw1EDTiUs5Idliee24xFg DbAZOMAxlcw8=; b=JPqSr4JB+Ioa/fe1vV6FMqtgCHUoUyXo5XsrCuv86wZEm7C Y7dSFigwFpvrvaFP6DGok9xYiUCFnVOuudTGRuaEpOaj/ayF7FPLs9itQ6fOpe0a YHLC2yCNEBCXOGvXHi8KHE38ZO7cyHN59l6gJmP1nyiwFC/G4mL9dYz770Sl/1Bk qFxz5BrnyrZzFRvTisgGXQw3ShX+Acj/OUN9aMmEjvaOv3otozCcWWhgtw6szxJ1 +ykjEYxBBGe4m77grY5erxfWIVq2BaZYRUAMXNaucY6W3tWhKNyGQyWNz3cDmc8l 9JiLT719nvLC7KEkplViSt92Owq+FbhgB548mfQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=OEUk/B J9UdMw1EDTiUs5Idliee24xFgDbAZOMAxlcw8=; b=Ra2b9H1sTxlh/XWO06sWPc 8amH+K4g2UVBanQuSYcJq4DiQqwkU3IBLDnF8yCUCu2aBcTb5Rvf5tIcjFOZ7EWb ggtRquezSS4f20cdPSDq/hslLrYiNVA89rU/JWyMAechSrCEIgEZWnqnQQynpOxp Qq4XDJlXgswhUND3heRJSy4sT+o3PU8jVW9HOsPx5+ZtrYnGJzj31X9FZRwg54tc nOmmARVvIa/nKGgcqdmgY2ZBPBM+lUuonoN6R5GjxOr296u30eETLIrjYxTZmtKA OoZ+sG/4JZCeB7bvRa2W2bYCUewHZ8cL04x6g3JF54j6WNgCwkFyzMv/SCRMGzhQ ==
X-ME-Sender: <xms:MMSOXMwfKvNLtOwcuFJKeKDguISnLJaCb06kLSn6iOHvPMJ0uKZvhA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrheelgdduheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhephhhtthhpshgvrhhvvghrthhoth grlhhkthhordhithdpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm theslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:MMSOXHKH794SBfQ7Hrn5UI7OgAJtNlAzO82j5t64AhxVqyaaG1uLjA> <xmx:MMSOXICp64GPe57LL_ZxXfdeMwYknT6uulhuD8kMtvSZ2JGygGJuDw> <xmx:MMSOXOdUCfPskSBXKgl5BJ-d5boA-5rrOwXMqoKr038iUymmaLA4AA> <xmx:McSOXCA5UnVzYAQepNu1fQbTSrO2v6xzDpF4ZmmrmVuMMJp8KnXtJA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CE6357C5FB; Sun, 17 Mar 2019 18:03:28 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <b3c252eb-f8de-42f7-bedd-ef23375b5325@www.fastmail.com>
In-Reply-To: <CAHbrMsCNyeabhk0sVexOHVedVkgG2dvV9T8wWL++om5juAUvEw@mail.gmail.com>
References: <CAHbrMsCNyeabhk0sVexOHVedVkgG2dvV9T8wWL++om5juAUvEw@mail.gmail.com>
Date: Sun, 17 Mar 2019 18:03:20 -0400
From: Martin Thomson <mt@lowentropy.net>
To: doh@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/VwOdy7aqvtv8JCXqnpusVkmPVso>
Subject: [Doh] Talking to my resolver
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Mar 2019 22:03:34 -0000

I've been uncomfortable about this draft for a while.  To be clear, I want some of what it sets out to accomplish, but the design gives me concerns that go beyond the short list of mildly offensive design characteristics.  It recently occurred to me that these are not so bad if they are necessary, but they might be a consequence of a deeper problem.  It's a problem that I think is entirely inappropriate for this working group to be tackling, but that didn't stop us from adopting the draft, so here goes...

The problem this attempts to address - at least in part - is talking to a resolver about the resolver itself.  In order to do that, it takes a rather circuitous route, depending on how many barriers there are.  Now I'm not deep enough into DNS to answer this question, but I wonder why we would ever design a system for talking to a resolver like the one proposed.

It barely uses the DNS protocol, meaning that it asks an HTTP server about a DNS server, even to the point of asking the DNS server to tell it which HTTP server to talk to.

It also fails to authenticate any of the information that is provided.  Arguably, none of this information can be authenticated given its origin, but the number of unauthenticated steps is typically limited, but here we have an additional exposure to attack.

It seems like the approach that has been taken with DoT is to try and see.  But we're all sufficiently scared of HTTP servers that we don't feel like that is a responsible thing to do with DoH.  And - more reasonably - we realize that having a way to find alternative endpoints for a resolver is worth having.  But why not provide a mechanism that can do for DoT what this does for DoH?  The draft provides two entirely bespoke names in the top-level .arpa space for DoH, but otherwise has no generalized characteristics whatsoever.

Maybe there is a better approach.

I don't know if there is any hope of adding a general facility to DNS where a client could talk to the server about itself, rather than the data that it can provide.  Most of what I can see in the protocol is concentrated on achieving some moving data in some way (RFC 6975 is almost there in talking about client capabilities).  Not knowing enough about the protocol, I can't say whether OpCodes, EDNS, or a reserved subtree is the right channel here, but it seems like ad hoc additions to the .arpa tree isn't as much a measured approach as simply a convenient one.

In HTTP we have started to use .well-known for providing resources that can talk about an origin as a whole.  That's a facility that this draft fixates on.  It's a convenient safety valve for those cases where the sophistication of the protocol starts to exceed the secondary channels provided in the protocol (EDNS in DNS, header fields in HTTP).

HTTP also has a convenient mechanism for doing exactly what this draft is attempting to do (almost, more later): find an alternative service endpoint for the current service, ideally one with better properties in some way.  RFC 7838 describes alternative services, which are implemented as a header field (here, an EDNS0 option seems like it might work).  In that design, a response from the resolver contains a list of alternative service endpoints, expressed as a tuple of name (and port) and endpoint type (using ALPN).  With some DNS-specific tweaks, I don't see why that would be a terrible approach here.

That design wouldn't work for all the stated use cases for resolver-associated DoH, but it would cover some of the more critical ones.  The main one that springs to mind being the web application case: as a web site, I want to make a DNS query from the perspective of my clients, so that (I can scan their network)^U I can find service endpoints more appropriate to their network location than mine.  I'd like to have a little more discussion of why we think that web sites might want to do their own DNS querying, but I don't believe that the current design helps web sites achieve this goal.

FWIW, I'm now unclear on why the draft calls "browsers" out specially.  Browsers aren't really special in this context.  You might reasonably care about three levels of things: devices (or operating systems), applications, and web sites.  The distinction between each being decreasing levels of access to information about their operating environment.  Applications might not know about their DHCP configuration and web sites generally can't directly access a DNS resolver directly.

--Martin

p.s., Happy to talk about how IP address certificates will make this difficult to deploy, but let's try to hit the high points first.

p.p.s., I really wish that DoT had decided to add some meta-information channel.  That solves a bunch of these issues.  I guess we can ALPN-up ourselves a v2 if we needed one.


On Sat, Mar 16, 2019, at 00:13, Ben Schwartz wrote:
> I'd like to thank the working group participants for the extensive 
> discussion of our most recent drafts. However, I would appreciate more 
> review of the Resolver-Associated DOH draft, which has the largest time 
> segment allocated for the upcoming meeting. This draft contains several 
> components that have been controversial in the past:
> 
> 1. IP-address certificates
> 2. A new .well-known endpoint
> 3. JSON
> 4. Recursive resolvers synthesizing responses as if they were 
> authoritative for certain names
> 5. Machine-readable content in a TXT record
> 
> Also, the draft does not enable the use of DoH if (1) an application 
> relies on POSIX-like DNS APIs to bootstrap AND (2) the resolver is only 
> reachable on a non-public IP address (e.g. RFC 1918). This is a side 
> effect of the requirement that the DoH server provide a valid 
> certificate for its name, chained to a root that is already trusted by 
> the client. This draft does not alter that requirement.
> 
> If any of these technical elements are of concern to you, please 
> comment now, so that the meeting can be as productive as possible.
> 
> --Ben
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
> 
> Attachments:
> * smime.p7s