Re: [Add] My principles for discovery

Tommy Pauly <tpauly@apple.com> Wed, 25 March 2020 23:42 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5743A077D for <add@ietfa.amsl.com>; Wed, 25 Mar 2020 16:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=apple.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 3XxBWdP_5v3q for <add@ietfa.amsl.com>; Wed, 25 Mar 2020 16:42:57 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C91A3A0768 for <add@ietf.org>; Wed, 25 Mar 2020 16:42:57 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 02PNVV2V046571; Wed, 25 Mar 2020 16:42:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=zD1zLKoxR1n/ZTCjmauIv2WVZWTdPK/qqreCJ5KL9aQ=; b=YCGcGTKv6NHIHTWlgSOxq+SS8u/RRfo9DOIN2976eHuUcoMTczQ0jX1BI55p82mCKQ+u mwhsP4IAgF2q81u/+QEqdhrN9+uK98rkmIITsSLNFfGR7zzID3zNS1E20lFnM0o9BaBf we79syqvd25orfGQgBd2VOZ2MXT0IkgwYHoTXAaq9aHsyIX4xQu3rj7ptc6LoOBado8k qKkSJJpf8lEqKHHcRFLt1TiMX+XpBUqXaNnrd4SeXWiW8iGqbZjUVZeJUvavRVr6cEYq TraVpjZm0F81NnVtYOiUni1H2rq2WsSyyv4LvBxoRD9ji6L1NQHM05BqiEhxY9ajPKd8 wg==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2ywhv38bd6-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Mar 2020 16:42:55 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q7R00D3YWJJYU90@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 25 Mar 2020 16:42:55 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q7R00Z00WFHG400@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 25 Mar 2020 16:42:55 -0700 (PDT)
X-Va-A:
X-Va-T-CD: c23d783ab285e2e2724c3baee78f3ad6
X-Va-E-CD: 1b29ea701340f768ed762e36645ac63e
X-Va-R-CD: a2264a257d6a417bba7f3da85f318e8e
X-Va-CD: 0
X-Va-ID: 9fb4c2a0-c335-4934-a14b-d641ec2ca89e
X-V-A:
X-V-T-CD: c23d783ab285e2e2724c3baee78f3ad6
X-V-E-CD: 1b29ea701340f768ed762e36645ac63e
X-V-R-CD: a2264a257d6a417bba7f3da85f318e8e
X-V-CD: 0
X-V-ID: 8e05cc82-c9b7-4857-bb2b-19b9187812fb
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-25_13:2020-03-24, 2020-03-25 signatures=0
Received: from [17.235.26.226] (unknown [17.235.26.226]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q7R00Z3IWJILQ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 25 Mar 2020 16:42:55 -0700 (PDT)
Sender: tpauly@apple.com
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <aec5404a-99eb-4aa7-9020-1e7b4f51b5ca@www.fastmail.com>
Date: Wed, 25 Mar 2020 16:42:54 -0700
Cc: add@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <2D741E61-9FFC-4A81-9EC6-274BC0AE68BF@apple.com>
References: <aec5404a-99eb-4aa7-9020-1e7b4f51b5ca@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-25_13:2020-03-24, 2020-03-25 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/UL8vzS9pIn8cXO8RGLMOB7RuADs>
Subject: Re: [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 23:43:00 -0000

Thanks for this summary, Martin. I completely agree that our focus on discovery as a group needs to be around how the entities a client interacts with offer resolver options to use, along with authentication of these options. The policy decisions of how to use the information is definitionally up to the client, and are not for this group to decide.

I also agree that the entities that might have opinions about resolver selection that are not a client device’s local network, or a server that the device interacts with during usage (such as the OS, application, or MDM configuration) belongs out of scope of any mechanisms we define here. Those boil down to a client policy. I certainly believe that operating systems and applications should be able to implement overriding policies for resolver selection, generally by user opt-in, but such an option is not part of “discovery”.

Any case in which a device dynamically chooses to use a discovered resolver does need to have some sort of authentication. Opinions from entities that the client does not have a relationship with are not useful.

However, when we discuss authentication of the resolver information, we may want to separate out:
- the fact that a given DoT/DoH resolver exists
- the opinion that a client *should* use this resolver for any given queries

I’d posit that the second part here is the more critical to authenticate.

I think any proposal that involves local-network provisioning (be that DHCP, RA, or a local PvD) can only provide the first part of indicating that a given resolver exists. I’d certainly prefer some signaling mechanism that is not too easy to spoof (hence my suggestion for the HTTPS-provided PvD JSON blob), but it’s relatively safe for a client to be aware of a resolver as long as it does not choose to use it until it learns more about it. Some solutions can provide authentication along with initial discovery (DNSSEC signed records, say), but the end set of solutions could include a combination of unauthenticated protocols for discovery that require later confirmation.

Thanks,
Tommy

> On Mar 24, 2020, at 9:36 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> 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.
> 
> Cheers,
> Martin
> 
> 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.
> 
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add