[Add] Charter proposal for ADD

Tommy Pauly <tpauly@apple.com> Tue, 28 January 2020 00:13 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 8C4683A1160 for <add@ietfa.amsl.com>; Mon, 27 Jan 2020 16:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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] 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 xNzPS-zezemQ for <add@ietfa.amsl.com>; Mon, 27 Jan 2020 16:12:59 -0800 (PST)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 88B413A115F for <add@ietf.org>; Mon, 27 Jan 2020 16:12:56 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 00S06pNm029131; Mon, 27 Jan 2020 16:12:54 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=Wz4xdJEy3+4khmJP2nYEBzcYNRRKMrERzcD+IwVhEnw=; b=Dy3n+DU6fOyVkOwlcMqtCVIW1jJWC0Iq2NH1KJfUx+1zDUmDdowKHKVqYFJ4aATWuxTq Whcr+vpmhhaHgtYQqKJdv6fcDS43o/OLQvzT74j2+h4/YZDdU3CJm7PXmlCb2JP0fZDE sdL9vCUk7crMT9gnEDREcnieAsNV6XLtu6JYus6S7PufkQOW/cy2EnVVbbKhjdu0BhpI jFdp9bIvgcDIzXui1XwlOYv5k5dHG6P4Tm+ZASlKTxyDApF5S5hCWcJKJCWbgBbbr9Ui s5ssR+XeKIEhEGoAWVfecy7upDk5SaUXq91bcFb/ahdRnZI+688xgKi2vWicYOUrXyXt 3A==
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2xs6snu3d6-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 Jan 2020 16:12:54 -0800
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4S00IWZJ9HM300@mr2-mtap-s02.rno.apple.com>; Mon, 27 Jan 2020 16:12:54 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q4S00J00J5WG600@nwk-mmpp-sz10.apple.com>; Mon, 27 Jan 2020 16:12:53 -0800 (PST)
X-Va-A:
X-Va-T-CD: 0084c17e20ec2f545a1482d82f00c392
X-Va-E-CD: 1baaae01cb3258383907d2b742351949
X-Va-R-CD: a4edbbbe8963e392a06fe37bd7a3f9cc
X-Va-CD: 0
X-Va-ID: e9dac653-b494-408e-a43b-d5799efb5809
X-V-A:
X-V-T-CD: 0084c17e20ec2f545a1482d82f00c392
X-V-E-CD: 1baaae01cb3258383907d2b742351949
X-V-R-CD: a4edbbbe8963e392a06fe37bd7a3f9cc
X-V-CD: 0
X-V-ID: ae24c978-0b5a-4b95-b0ac-8dbc8a4a272f
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-27_08:,, signatures=0
Received: from [17.192.171.152] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q4S00KHOJ9HS340@nwk-mmpp-sz10.apple.com>; Mon, 27 Jan 2020 16:12:53 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Message-id: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com>
Date: Mon, 27 Jan 2020 16:12:49 -0800
To: ADD Mailing list <add@ietf.org>, Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-27_08:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/mDkDvuLVn4jsb4UNHAMjyOsNJXo>
Subject: [Add] Charter proposal for ADD
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: Tue, 28 Jan 2020 00:13:01 -0000

Hi ADD,

As our discussion on the proposed charter has quieted down, I wanted to send a brief update and summary.

The main point of discussion was the paragraph on security requirements that began "Any mechanisms that...". As many people stated on the previous thread, the necessity for security considerations and security area review in work produced by an IETF working group is already well-established, so this text is not needed specifically in this charter. There were some proposals to tweak the language, but on the whole, it seems that we can live without that paragraph.

Jari also had a good suggestion to include a sentence about the impact of resolver selection (on reachability and privacy, etc). After looking at adding that text, I am concerned that adding it to the charter gets into too many details that really belong in the WG documents, particularly around how to assess the "privacy" implications of choosing one resolver over another. The charter does indicate that these mechanisms are being used to "provide benefits to the security and privacy of DNS data", and it does cover reachability with the example of "a resolver may be able to resolve private or local names...". As such, I'd prefer to not add any new sentence for now (and Jari indicated he could live with the text as is!).

I've included the updated proposal, which matches the previous proposal and removes the text on security requirements. Based on the previous thread, this should represent the consensus of the list.

Barry, can you help get this started in the process of chartering?

Best,
Tommy



Adaptive DNS Discovery (ADD)
====================================
Proposed Working Group Charter

Sending DNS messages over encrypted transports, as defined in DNS over
TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides
benefits to the security and privacy of DNS data. Clients, such as
applications and host operating systems, have started adopting these
protocols to provide these user benefits.

This working group will focus on discovery and selection of DNS resolvers
by DNS clients in a variety of networking environments, including public
networks, private networks, and VPNs; supporting both encrypted and
unencrypted resolvers.

Clients adopting encrypted DNS protocols need to determine which DNS
servers support encrypted transports, and which server to use for specific
queries if multiple servers are available. These decisions can vary based
on the network environment, and also based on the content and purpose of
the client queries.

Network operators that start offering DNS encryption on their servers also
need a way to indicate this support to clients. Communicating information
about resolver configuration and behavior allows clients to make more
informed decisions about which DNS servers to use. For example, a resolver
may be able to resolve private or local names as a split DNS server.

The Adaptive DNS Discovery (ADD) working group will work on the following
deliverables:

- define a mechanism that allows clients to discover DNS resolvers,
including encrypted DNS servers, that are available to the client
either on the public Internet or on private or local networks;

- define a mechanism that allows communication of DNS resolver
information to clients for use in selection decisions;

- develop an informational document that describes how client
applications and systems can manage selection of DNS resolvers
in various network environments and use cases.

This working group will coordinate with dnsop, doh, and dprive for any
changes required in DNS protocols. It will also work with capport to
ensure that solutions are applicable to captive networks.