[Add] My principles for discovery

Martin Thomson <mt@lowentropy.net> Wed, 25 March 2020 04:37 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 923D43A0811 for <add@ietfa.amsl.com>; Tue, 24 Mar 2020 21:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=G5WfF9EG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sYE/E9Uk
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ijrrgqAZDluj for <add@ietfa.amsl.com>; Tue, 24 Mar 2020 21:37:12 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A643A00C9 for <add@ietf.org>; Tue, 24 Mar 2020 21:37:11 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 1754C547 for <add@ietf.org>; Wed, 25 Mar 2020 00:37:11 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Wed, 25 Mar 2020 00:37:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=qpBA3UiPG9n89mfMPiF02v5XMRRwVtkuZfUzjP/L+no=; b=G5WfF9EG 2YJwntuc+tRrT68mF8zr8d9WSHzC2vM3g4YIPot29iVBdvjuREKZ0yfZ7SWrFp8X PsHi0bt9634oKoYi67BxIsj6cGpWNMXa5j+iK2YsacAUSzpZQSv3tKke+Ej3RgfW 41qmek8JZ+chnRiwI665PAndyiCFvavrM5wrgv5+xENf6IqJQgqoB2TZCr/5y2/x qKRhi7B9EUD+7veWbrKtt2gAJARO+/nMROgetepC/zIPhh4tyzPODMRlV2JNTCjj KlQCZmwJjayYKSQrLJlGwAygMzPsBoq9ISOXAAgdJjTUiPhoZItyLN3wg9BOKGRq gfsQBx6Y4EdxQw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=qpBA3UiPG9n89mfMPiF02v5XMRRwV tkuZfUzjP/L+no=; b=sYE/E9UkfcDPYx4d5epPKRO6C0O6H8HEWZExfP8qcTwaw nraQaKKk7vZ9LyhvzWY49cmqrQr2+bpNj+8R8JUlNB5pDyRHVpZKaPQ8T6FNb2Dn jtYtrcy1FTt/fHENiYKO1MS7Bx72vPAoBVb0nTO8W6/f+HJgEAq4fKP9mcBl7FG/ mNwTfYitLh6zP8OR54TO5kLkxwKbcO0bCYBzZp4kzuu+xUBjPecnVrcJjCdqqFbM vbQ/VM1yL+bHxMBIsy0GjwkNXDcgtIa5S3FLIJkfaq4DzDn5IKMTucyAWwnq4B/6 t75BQuAJ92Z4EQ0NrfnSFNtVWFzRczBxPDfKX1SGg==
X-ME-Sender: <xms:9t96XhukMIEPIE9oYYGQ4MO_9_ae31FxlWr-T1N0Zk5EDyQlz5q5Gg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehvddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:9t96XrMl0up7mVIUoRFOlhePq-z2jXH3cKdUs6bytLwj03PiHjKbZg> <xmx:9t96XkbwzRaE7PQEJ4hsCyVmTZmU50crFcnlKhUx20-AvVDjUKj49Q> <xmx:9t96Xha5gu8y1BdGP4XWvGMSo3EZZG2qysRfvorOnbyruJWmcsefLg> <xmx:9t96Xnz6321BrMuE651bfPEFtpzeIF6Aq6wgcdCeNJHqGu82IOWmDQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7178CE0107; Wed, 25 Mar 2020 00:37:10 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1
Mime-Version: 1.0
Message-Id: <aec5404a-99eb-4aa7-9020-1e7b4f51b5ca@www.fastmail.com>
Date: Wed, 25 Mar 2020 15:36:51 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: add@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/HYwdk-vvlrKgdjuaUbb65_xbhng>
Subject: [Add] My principles for discovery
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2020 04:37:14 -0000

As I raised this in the meeting, I think that it's only fair that I include what I think the principles should be.

In short, I believe that any entity that you interact with should be able to present their views on what resolver you should use.  Client policy will then dictate which - if any - of those is used.  Authentication of the source of these opinions is likely a necessary input for the client policy decision.

It is discussing client policy that has caused us to get into unproductive discussions.  To be clear, I regard the question of whether it is users or the software they choose to run that make policy decisions to be firmly part of this discussion.  We might variously lament the ability of software to properly reflect the wishes of users, but this is not the place to debate that.

That doesn't mean that you should expect the person serving you sausages at a local deli to offer an opinion on what resolver you should use.  But we should look to provide ways in which entities that have some relevant stake to make their opinion known.  As a provider of application software that might be interested in having its own policies, I might expect to receive opinions from the following places:

* The networks that endpoints connect to.
* DNS servers that might be involved in answering queries.
* Other communication endpoints, such as sites or enterprise services, and their representatives, such as CDNs or corporate IT.

These next three might not depend on a protocol that we define here, but we can still recognize that there might be other entities involved in expressing opinions and - for these - even setting policy:

* The operating system configuration.
* Various "owners" or stakeholders for the endpoint, such as an employer or a government (this might not extend all the way to full control of the device MDM-style, but it might still be relevant to the client policy).
* Application configuration.

I don't personally see a lot of value in having entities other than those from the first set of three stand on soapboxes to broadcast their opinions about resolver choice, but there is nothing fundamentally wrong with having other sources of opinions.  So while the IETF could provide more protocols, it's not a good use of our time and resources unless we expect that the information would be acceptable to genuine client policies.

When it comes to setting policy, authentication is important.  When making a decision about whether to use a particular resolver, depending on the policy you have, it might be important that you know whose opinion is guiding the decision.  If you want a server that doesn't store logs of queries for longer than a certain time, then I'm not aware of a technical mechanism for verifying that claim.  You likely have to rely on the assertions of an entity you trust.  Opinions received over the delicatessen counter are unlikely to carry any particular weight.

It was good to see both Tommy and Dan address this question directly; though I'm not sure I totally agree that the right trust anchors were used, building in ways to authenticate an opinion makes it more likely that client policy will allow use of the indicated resolver.

I think that the need to be flexible about authenticity derives largely from the desire to allow networks to have an opinion.  I know of no way to authenticate the output of DHCP or a RA, except to say that this is most likely the provider of the network who is speaking.  That's very weak authentication, so while it carries some weight, it's not a lot.

So, I would suggest that the best we can hope for from this WG is a set of mechanisms that report on resolver options/opinions and some associated information that includes who provided the option/opinion and how.


p.s., Regarding work on the table, I think that it is clear what the models are driving draft-btw-add-home, draft-peterson-do[th]-dhcp, and draft-pauly-dprive-adaptive-dns-privacy.  I struggle a little with draft-mglt-add-rdp in this regard and I would appreciate a little more clarity about intent.  It is possible that draft-reddy-add-server-policy-selection is firmly in the authentication space, but it seems to be more firmly aimed at communicating policy than I am currently comfortable with right now.