From nobody Tue May 5 07:40:21 2020 Return-Path: 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 E61E53A074E for ; Tue, 5 May 2020 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hnVey7z0_l-5 for ; Tue, 5 May 2020 07:40:17 -0700 (PDT) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FA43A0C03 for ; Tue, 5 May 2020 07:39:47 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 61794B9D0F; Tue, 5 May 2020 10:39:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24241.31410.380560.155729@gro.dd.org> Date: Tue, 5 May 2020 10:39:46 -0400 From: Dave Lawrence To: add@ietf.org Reply-To: ietf108planning@ietf.org Archived-At: Subject: [Add] Reminder: Survey on planning for possible online IETF meetings X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 14:40:19 -0000 Redistributed by request. If you participate in working group meetings your feedback is very important to help determine the logistics of upcoming IETF meetings. https://www.surveymonkey.com/r/5328FFJ Note that I've set the Reply-To for this message to the one of the original message (or tried; I don't know if the list software lets that through). ------- start of forwarded message (RFC 934 encapsulation) ------- From: IETF Executive Director Subject: Reminder: Survey on planning for possible online IETF meetings To: "IETF Announcement List" Date: Mon, 04 May 2020 00:03:35 -0700 Reply-To: ietf108planning@ietf.org This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. You can help us with this by filling out the following survey: https://www.surveymonkey.com/r/5328FFJ So far we have 114 responses and we would ideally like 500 or more. The survey contains the following pages and will take 15-20 minutes to complete: 1. Welcome 2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting 4. Online meeting format and timezone 5. Replicating humming 6. Replicating the hallway environment 7. Fees 8. Thanks and anything else We run the survey in anonymous mode which means that we only see data that you explicitly provide. Thank you in advance for your help. - -- Alissa Cooper, IETF Chair Jay Daley, IETF Executive Director Colin Perkins, IRTF Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------- end ------- From nobody Wed May 6 05:19:08 2020 Return-Path: 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 387263A09ED for ; Wed, 6 May 2020 05:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 clRDF6HIHXtg for ; Wed, 6 May 2020 05:19:04 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 42F243A09D2 for ; Wed, 6 May 2020 05:19:04 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id e9so1843037iok.9 for ; Wed, 06 May 2020 05:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eoQ1IrCtnqCKdiq7wFddoeSjBZgXnQNY4ZaNjmuT1pQ=; b=YPL90nEq4z7VBY2mj3BKB8yZOYE+2veUfCToU04nL1PaZl0adgRQvNMBY79uD6KarD 5dph1Ph1gJODhrZMqjrQAXfEvjQgeSZxO0fjJ3VCcnZoOfviu4O+c/446MCGOyLyEOlK C2pwpKfm14x3F479WoFRBezRKk5Xq1QNm9u3haTaUQx0e16IkC4ShyFwo4o9XKHjO0qe DxNCpSq+AAITXvKVohW2ttWLZeQmCYyLQuqsKiF/IRxTpXoE7Spwy562N/2jGiesagrT nSJ+FtFEjDVU+w3ywITqKnKbnIb6texv+qjEUXWOj32C+MHq4ZFXN2vm1/i6nj6s8+pd WpwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eoQ1IrCtnqCKdiq7wFddoeSjBZgXnQNY4ZaNjmuT1pQ=; b=tY4oS8LyP/5kgFa2TsYDC9gdTehvagceTK+urJRXkYmYF3PeaLtavvSzSyvTXMuQcH CshyPUMbI36sMVLZgx+OLeZOitAhpPs9nFV6ZBy2fZcRXwVtPCiFMGuM/qgEr+w9HY7q PsLis1xbs6LWn8qzjqCfriIneVjkbrNl4KiUTblmZE/G+SFeMWQmO9+WVkNmwNnOy8Ep s+PaxRxFtFKO4iDLKfVkLGjDLFFEQu9izt54R6963vO81iH95yPgwccV4zcWmb9wLOIh 9q8TV0mU29z8+Lvde4NXB1PmWCuA1S6mgAdr/OvbCZ6+4TIDsEx5id6CElampEtxgGc3 UFnQ== X-Gm-Message-State: AGi0PuZqAVxFpzK0slYC/DfMryP3DcHmwQrDNwuDmzKMb3BaxXUy//1I jfiU8a7BXGcmHnqNDb7iK0DG0Cg6XgqY1c1fdNjHzkCv X-Google-Smtp-Source: APiQypLmz6rH9Hgz8/ILkmNWfr/OYzb6QYWrosG95AYB21F3wMkEcWaCjMVsfFrR/z/gIULYoYpbS2HRLvKdkMxduho= X-Received: by 2002:a02:7f12:: with SMTP id r18mr8275423jac.75.1588767543064; Wed, 06 May 2020 05:19:03 -0700 (PDT) MIME-Version: 1.0 References: <158867945708.16793.2741829004365163405@ietfa.amsl.com> In-Reply-To: <158867945708.16793.2741829004365163405@ietfa.amsl.com> From: tirumal reddy Date: Wed, 6 May 2020 17:48:51 +0530 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000008fdba05a4f9c58d" Archived-At: Subject: [Add] Fwd: New Version Notification for draft-reddy-add-iot-byod-bootstrap-00.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:19:06 -0000 --00000000000008fdba05a4f9c58d Content-Type: text/plain; charset="UTF-8" Hi all, This draft https://tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-00 discusses mechanisms to bootstrap IoT and BYOD devices to securely discover and authenticate DoT/DoH servers provided by the Enterprise network. It discusses (1) Bootstrapping phase to securely bootstrap IoT and BYOD devices with the authentication domain name (ADN) and DNS server certificate of the Enterprise's DNS server. (2) Connection handshake and DNS server certificate validation. Comments and suggestions are welcome. Cheers, -Tiru ---------- Forwarded message --------- From: Date: Tue, 5 May 2020 at 17:20 Subject: New Version Notification for draft-reddy-add-iot-byod-bootstrap-00.txt To: Mohamed Boucadair , Tirumaleswar Reddy.K < kondtir@gmail.com>, Dan Wing , Michael C. Richardson A new version of I-D, draft-reddy-add-iot-byod-bootstrap-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-add-iot-byod-bootstrap Revision: 00 Title: A Bootstrapping Procedure to Discover and Authenticate DNS-over-TLS and DNS-over-HTTPS Servers for IoT and BYOD Devices Document date: 2020-05-05 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-reddy-add-iot-byod-bootstrap-00.txt Status: https://datatracker.ietf.org/doc/draft-reddy-add-iot-byod-bootstrap/ Htmlized: https://tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-add-iot-byod-bootstrap Abstract: This document specifies mechanisms to bootstrap endpoints (e.g., hosts, IoT devices) to discover and authenticate DNS-over-TLS and DNS-over-HTTPS servers provided by a local network for IoT/BYOD devices in Enterprise networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000008fdba05a4f9c58d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

This draft=C2=A0https:= //tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-00=C2=A0discus= ses mechanisms to bootstrap IoT and BYOD devices to securely discover and a= uthenticate DoT/DoH servers provided by the Enterprise network. It discusse= s

(1) Bootstrapping phase to securely bootstrap IoT and BYOD device= s with the authentication domain name (ADN) and
DNS server certificate = of the Enterprise's DNS server.

(2) Connection handshake a= nd DNS server certificate validation.

Comments and suggestions are w= elcome.

Cheers,
-Tiru

---------- Forwarded message ---------
Fro= m: <internet-drafts@ietf.org>
Date: Tue, 5 May 20= 20 at 17:20
Subject: New Version Notification for draft-reddy-add-iot-by= od-bootstrap-00.txt
To: Mohamed Boucadair <mohamed.boucadair@orange.com>= ;, Tirumaleswar Reddy.K <kondtir@gmail.com>, Dan Wing <dwing-ietf@fuggles.com>, Michael C.= Richardson <mcr+ietf@sandelman.ca>



A new version of I-D, draft-reddy-add-iot-byod-bootstrap-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-add-iot-byod-boot= strap
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Bootstrapping Procedure to Disco= ver and Authenticate DNS-over-TLS and DNS-over-HTTPS Servers for IoT and BY= OD Devices
Document date:=C2=A0 2020-05-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-reddy-ad= d-iot-byod-bootstrap-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-reddy-add-iot-byod-bootstra= p/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-reddy-add-iot-byod-boot= strap


Abstract:
=C2=A0 =C2=A0This document specifies mechanisms to bootstrap endpoints (e.g= .,
=C2=A0 =C2=A0hosts, IoT devices) to discover and authenticate DNS-over-TLS = and
=C2=A0 =C2=A0DNS-over-HTTPS servers provided by a local network for IoT/BYO= D
=C2=A0 =C2=A0devices in Enterprise networks.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--00000000000008fdba05a4f9c58d-- From nobody Thu May 14 10:14:57 2020 Return-Path: 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 F0EDA3A0C23 for ; Thu, 14 May 2020 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 J1tLjTEQ7iAq for ; Thu, 14 May 2020 10:14:53 -0700 (PDT) Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 C7DFD3A0C1D for ; Thu, 14 May 2020 10:14:51 -0700 (PDT) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 04EHEovc001952 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 14 May 2020 17:14:51 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 10:14:49 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Thu, 14 May 2020 10:14:49 -0700 From: Paul Hoffman To: ADD Mailing list Thread-Topic: New versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo Thread-Index: AQHWKhMsJppvnu/p6EyJyz7aXZKBJA== Date: Thu, 14 May 2020 17:14:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_33C4565F-8D95-4867-9809-CAE352BD7359"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-14_05:2020-05-14, 2020-05-14 signatures=0 Archived-At: Subject: [Add] New versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 17:14:55 -0000 --Apple-Mail=_33C4565F-8D95-4867-9809-CAE352BD7359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings again. Puneet and I have made fairly major changes to = draft-pp-add-stub-upgrade and draft-pp-add-resinfo based on the traffic = from the WG earlier. The drafts are now focused on the much-more-common = use case of a stub having an IP address that it got over an = unauthenticated channel such as DHCP, and we thus removed getting the = information over HTTPS. The new drafts are at: https://www.ietf.org/internet-drafts/draft-pp-add-stub-upgrade-01.txt https://www.ietf.org/internet-drafts/draft-pp-add-resinfo-01.txt If folks like the new focus, we can ask the WG chairs to adopt them. We = know that much of the interest in the WG is on discovery, not this = simple upgrade process, so we figured we could get these done more = quickly while the bigger discussions are happening. --Paul Hoffman= --Apple-Mail=_33C4565F-8D95-4867-9809-CAE352BD7359 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwNTE0MTcxNDQ5WjAvBgkqhkiG9w0BCQQxIgQgDgm0FzuZt3watLNFrN8zvue7M65Q RmXeo4CzyuwwQ7UwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAD+EZIVKox0HRFnoKDY9PqOt9xHjUPGume/sOljPikmt I3YvfNoQ5tfULp7LzuqTx1Hbu24UFBltXHLinmMhfanzU5vzOV3mCuPN62qZDVSEqUDnoCP9fd3T GV9r8rrDU+jGMDj/MDuRGQRjl7XeiNfywO4U6zhwDo9vQRJmVprVG0A/YHOPS+CegEHcQWpWN8Ld TjYI3JGkFnkUXR18bhr0FJM8faorRV95RyurhNKOz4A6ei+N7+c6OrFKqBKGLmLmfrT5PbSbYlOd tyIyyNir5fZoa48kBZkzm6IsxVRtqkpmcDbLSs6BMltoHxGF+TkQai3TlFNppgCmsdjdcaQAAAAA AAA= --Apple-Mail=_33C4565F-8D95-4867-9809-CAE352BD7359-- From nobody Fri May 15 11:23:39 2020 Return-Path: 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 72AAB3A0B15; Fri, 15 May 2020 11:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 yMpoKkpZA4sS; Fri, 15 May 2020 11:23:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA68A3A0AA0; Fri, 15 May 2020 11:23:35 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 49NxcQ1LD6z5vwH; Fri, 15 May 2020 20:23:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1589567014; bh=/XWMxH68OM1zErf7siAJRg0rWl1j0f4KyIDnB9fpyUs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=V/EHRDiXkU9Ql2b2vggPC0CnAgeJbXJvpcoqAJL3wAAkzLbi7pcnRcpJabZRQNMBR r6CVsqmbd/TLpC2aBYIHoQzivuKMJR9vG/KJW8SuCK2ULDaHgRk9lMxURKRlugnsh3 ZF0DbKCdVdafH7vADxwTFhWKnGdTAE2TWtSYeTdAwvggvVjfxyhj+OVEWAxrM0tJ+b P4LS1Y4xAFGLEubKJoH2cFnt2Ev3IKBHH4eLY6cQ3IXdtwAhHBPP3cvkji9PVCI9xi 5evleG/7POhWmwuxPklEFEHtYBy1A88HdwI1TKIaBUaZ+1hE533a90+Sj5MokEsveb 1E+5f/PeqM49Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 49NxcQ0VxBz1xp6; Fri, 15 May 2020 20:23:34 +0200 (CEST) From: To: "ADD Mailing list (add@ietf.org)" CC: "draft-btw-add-home@ietf.org" Thread-Topic: New Version Notification for draft-btw-add-home-06.txt Thread-Index: AQHWKuSkcdr9hBtKGkuuf1E+xpvZXaipdA4g Date: Fri, 15 May 2020 18:23:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314BDADF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158956645261.27084.3760147104290113368@ietfa.amsl.com> In-Reply-To: <158956645261.27084.3760147104290113368@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Add] TR: New Version Notification for draft-btw-add-home-06.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 18:23:38 -0000 RGVhciBhbGwsIA0KDQpXZSBwcmVwYXJlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRyYWZ0 IHRvIGJhc2ljYWxseSBzaW1wbGlmeSB0aGUgcHJvY2VkdXJlIGZvciBob3N0aW5nIGEgZm9yd2Fy ZGVyIG9uIHRoZSBDUEUuIFdlIHJlbW92ZWQgdGhlIHByb3Bvc2FsIHJlbHlpbmcgdXBvbiBEb0gg cmVkaXJlY3Rpb24uIA0KDQpXZSBtYWRlIG90aGVyIG1vZGlmaWNhdGlvbnMgc3VjaCBhcyBkZWxl dGluZyB0aGUgbm90ZSBhYm91dCB0aGUgdXNlIG9mIERIQ1AvUkEgdG8gY29udmV5IHRlbXBsYXRl cywgd2UgcmVseSBvbiBJLUQucHAtYWRkLXJlc2luZm8gaW5zdGVhZC4gDQoNCkNvbW1lbnRzIGFy ZSB3ZWxjb21lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KRGXCoDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANCkVudm95w6nCoDogdmVuZHJlZGkgMTUgbWFpIDIwMjAgMjA6MTQNCsOAwqA6 IFRpcnVtYWxlc3dhciBSZWRkeTsgVGlydW1hbGVzd2FyIFJlZGR5Lks7IE5laWwgQ29vazsgQk9V Q0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgRGFuIFdpbmcNCk9iamV0wqA6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtYnR3LWFkZC1ob21lLTA2LnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1idHctYWRkLWhvbWUtMDYudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1vaGFtZWQgQm91Y2FkYWlyIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1idHctYWRkLWhvbWUNClJldmlzaW9uOgkwNg0K VGl0bGU6CQlFbmNyeXB0ZWQgRE5TIERpc2NvdmVyeSBhbmQgRGVwbG95bWVudCBDb25zaWRlcmF0 aW9ucyBmb3IgSG9tZSBOZXR3b3Jrcw0KRG9jdW1lbnQgZGF0ZToJMjAyMC0wNS0xNQ0KR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjMNClVSTDogICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnR3LWFkZC1ob21lLTA2LnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWJ0dy1hZGQtaG9tZS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnR3LWFkZC1ob21lLTA2DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1idHctYWRkLWhvbWUNCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYnR3LWFkZC1ob21lLTA2 DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgRG9UL0RvSCBkZXBsb3lt ZW50IGNvbnNpZGVyYXRpb25zIGZvciBob21lDQogICBuZXR3b3Jrcy4gIEl0IHBhcnRpY3VsYXJs eSBza2V0Y2hlcyB0aGUgcmVxdWlyZWQgc3RlcHMgdG8gdXNlIERvVC9Eb0gNCiAgIGNhcGFiaWxp dGllcyBwcm92aWRlZCBieSBsb2NhbCBuZXR3b3Jrcy4NCg0KICAgVGhlIGRvY3VtZW50IHNwZWNp ZmllcyBuZXcgREhDUCBhbmQgUm91dGVyIEFkdmVydGlzZW1lbnQgT3B0aW9ucyB0bw0KICAgY29u dmV5IGEgRE5TIEF1dGhlbnRpY2F0aW9uIERvbWFpbiBOYW1lLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KDQo= From nobody Sat May 16 13:09:27 2020 Return-Path: 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 9332A3A08D3 for ; Sat, 16 May 2020 13:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 3uH_vk9nZ4vA for ; Sat, 16 May 2020 13:09:23 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 99E043A08CA for ; Sat, 16 May 2020 13:09:23 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id v12so7254396wrp.12 for ; Sat, 16 May 2020 13:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T/xpcdvbnkp3qRENiKdUI+jXl2BboixP9mY7wtW9WXI=; b=U4hxDW+lW37JjSTGp+/mrU29WD5ZAr663wFU55Ig3ID8x0MRKxmqcM2Wz9Aq3CCcjL dydUbO1zcd+DP0jCYWrzwXADqGzZWNWEN581dfKnps4fRrWU0zd7CLdlzV/yHk5uWMJH 62GCEknSpEdkcdkTTa6BTTjmv5iNPHn3vrRoCsq7oRMwze4ODq+aO8uPVPJa9gbM3qeU 8gyrVInx5KVWgbQz86T+P2gXSy2bzLCgm2VG/AsEhMSnGXHHoasiNa+xok8QUZZTZBEK s0mMGBClEbFetqTfbhytdQKSntn/jtVyabCJLSt+eiVMlAQD21AxltAp8W61lEwgENzr Z6Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T/xpcdvbnkp3qRENiKdUI+jXl2BboixP9mY7wtW9WXI=; b=OiFMszCThwr3u3cWi7fr6RYFXyCxd1FMjT41ham2sTjQf8QOHUpO+er33t05UbEr4U D6P/xaQvlJkuy5VAuxp+3u+LJWK2/Uk0C5NiyZ2Ez6c+bpzieyTMM4r9jFzprrx+8arj 4sRKTq9MwBZlHQO93OwM2NayeHjEJXhGvU72kMEhSoUs1QI42FoeAKCuICWTDLcmhIJr tvqa8DlfPKgMs1PSA6VsQnZreUJ8onPh+h0s+gHmbobZHfCd6C2I62MbRfpcTLM3b3Lq jDE356nFwhQjBOCS7wd7X7s59+02ZbUtyc3O9dJOHsVfEiLV3KQdmTLxwpe4FSeF6i3x OnWQ== X-Gm-Message-State: AOAM532bcPQveq/pb7KH9OZSsR4fVvI3jclEfKETnsmgAFmOPU6Sb5hv 01LOX4/iBLYhdeS+6XZfVoBUBQy+h3VasbgSAZwQbg== X-Google-Smtp-Source: ABdhPJxanbmD4qGqlqFeogHPY3/J5zEIkQZvPTevRloslWNrTKQOaY1pJmXq8mMp2qHD4svzi5AoF2aJ5F6D10qfVvM= X-Received: by 2002:adf:dcc8:: with SMTP id x8mr10879223wrm.404.1589659761485; Sat, 16 May 2020 13:09:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Sat, 16 May 2020 16:09:09 -0400 Message-ID: To: Paul Hoffman Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007139ca05a5c9810d" Archived-At: Subject: Re: [Add] New versions of draft-pp-add-stub-upgrade and draft-pp-add-resinfo X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 20:09:26 -0000 --0000000000007139ca05a5c9810d Content-Type: multipart/alternative; boundary="00000000000066103905a5c9811d" --00000000000066103905a5c9811d Content-Type: text/plain; charset="UTF-8" Thanks; I like this version of RESINFO. Some comments on Section 2: * "... it can use that configuration to actually be authoritative for the addresses on which it responds." -> I don't understand what an "address" is in this sentence. Does it refer to a reverse-IP name? Or to the hostname of the resolver, in cases where the resolver has a known name (e.g. DNS-over-TLS)? * "Any query for the RESINFO RRtype that does not have a QNAME of resolver-info.arpa/IN is meaningless and MUST result in a NODATA or NXDOMAIN response." -> I would like this to be relaxed (see proposal below). I have more problems with the "Upgrade" draft: Section 2.1: * "dot-ports" -> I think this should be "dot-addresses" in hostname:port syntax, to enable authentication. The "hostname" part can be optional to indicate "same IP, unauthenticated". * "The host part of the URI template MUST be an IP address." -> I think this is exactly wrong. IP address certificates provide less security than named certificates, and are also dramatically more difficult to acquire. I would remove this requirement, and also change the examples to use named URLs. Section 3: * "upgradeNoAuth" -> I think this should be removed. If the resolver claims a name, we should always validate, and fail hard if validation fails. * "start TLS session on resIP port 443" -> I don't understand the intent of this algorithm, but it does not support HTTP/3, nor URLs with non-default ports. It also seems to imply that the DoH server must run on the same IP address as the Do53 server, which is not true for many major deployments. I would replace this entire section with "Do DoH". * This section is missing "just try TLS on port 853", which is the status quo for DoT upgrade. Proposal: DNSSEC-authenticated RESINFO for named resolvers Most resolvers are known to the client by their IP (learned via DHCP, etc.). However, there are some systems (e.g. Android) that allow the user to identify a preferred resolver by hostname. I propose that any resolver that is known to its clients by hostname (currently only DoT resolvers) MUST additionally publish its RESINFO record on its hostname, and clients MAY query $hostname/IN/RESINFO instead of resolver-info.arpa/IN/RESINFO. This would enable authentication of RESINFO for clients who perform DNSSEC validation and have a resolver identified by hostname. Possible use cases: * Authenticated DoH to named resolvers without also having to implement DoT (and without requiring the user to provide the full DoH URI template). * Authentication and non-repudiability of (TBD) non-upgrade-related metadata in RESINFO. On Thu, May 14, 2020 at 1:15 PM Paul Hoffman wrote: > Greetings again. Puneet and I have made fairly major changes to > draft-pp-add-stub-upgrade and draft-pp-add-resinfo based on the traffic > from the WG earlier. The drafts are now focused on the much-more-common use > case of a stub having an IP address that it got over an unauthenticated > channel such as DHCP, and we thus removed getting the information over > HTTPS. The new drafts are at: > > https://www.ietf.org/internet-drafts/draft-pp-add-stub-upgrade-01.txt > https://www.ietf.org/internet-drafts/draft-pp-add-resinfo-01.txt > > If folks like the new focus, we can ask the WG chairs to adopt them. We > know that much of the interest in the WG is on discovery, not this simple > upgrade process, so we figured we could get these done more quickly while > the bigger discussions are happening. > > --Paul Hoffman-- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000066103905a5c9811d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks; I like this version of RESINFO.=C2=A0 Some comment= s on Section 2:
* "... it can use that configuration to actually b= e authoritative for the addresses on which it responds." -> I don&#= 39;t understand what an "address" is in this sentence.=C2=A0 Does= it refer to a reverse-IP name?=C2=A0 Or to the hostname of the resolver, i= n cases where the resolver has a known name (e.g. DNS-over-TLS)?
= * "Any query for the RESINFO RRtype that does not have a QNAME of reso= lver-info.arpa/IN is meaningless and MUST result in a NODATA or NXDOMAIN re= sponse." -> I would like this to be relaxed (see proposal below).

I have more problems with the "Upgrade" d= raft:
Section 2.1:
* "dot-ports" -> I thin= k this should be "dot-addresses" in hostname:port syntax, to enab= le authentication.=C2=A0 The "hostname" part can be optional to i= ndicate "same IP, unauthenticated".
* "The host pa= rt of the URI template MUST be an IP address." -> I think this is e= xactly wrong.=C2=A0 IP address certificates provide less security than name= d certificates, and are also dramatically more difficult to acquire.=C2=A0 = I would remove this requirement, and also change the examples to use named = URLs.

Section 3:
* "upgradeNoAuth&q= uot; -> I think this should be removed.=C2=A0 If the resolver claims a n= ame, we should always validate, and fail hard if validation fails.
* "start T= LS session on resIP port 443" -> I don't understand the intent = of this algorithm, but it does not support HTTP/3, nor URLs with non-defaul= t ports. It also seems to imply that the DoH server must run on the same I= P address as the Do53 server, which is not true for many major deployments.= I would replace this entire section with "Do DoH".
* This secti= on is missing "just try TLS on port 853", which is the status quo= for DoT upgrade.

Proposal: DNSSEC-authenticated RESINFO for named reso= lvers
Most resolvers are known to the client by their IP (learned= via DHCP, etc.). However, there are some systems (e.g. Android) that allo= w the user to identify a preferred resolver by hostname. I propose that an= y resolver that is known to its clients by hostname (currently only DoT res= olvers) MUST additionally publish its RESINFO record on its hostname, and c= lients MAY query $hostname/IN/RESINFO instead of resolver-info.arpa/IN/RESI= NFO. This would enable authentication of RESINFO for clients who perform D= NSSEC validation and have a resolver identified by hostname.<= /div>

=
Possible use cases:
* Authenticated DoH to named resol= vers without also having to implement DoT (and without requiring the user t= o provide the full DoH URI template).
* Authentication and non-= repudiability of (TBD) non-upgrade-related metadata in RESINFO.

On Thu, May 14, 2020 at 1:15 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings again. Puneet and I= have made fairly major changes to draft-pp-add-stub-upgrade and draft-pp-a= dd-resinfo based on the traffic from the WG earlier. The drafts are now foc= used on the much-more-common use case of a stub having an IP address that i= t got over an unauthenticated channel such as DHCP, and we thus removed get= ting the information over HTTPS. The new drafts are at:

https://www.ietf.org/internet-d= rafts/draft-pp-add-stub-upgrade-01.txt
https://www.ietf.org/internet-drafts= /draft-pp-add-resinfo-01.txt

If folks like the new focus, we can ask the WG chairs to adopt them. We kno= w that much of the interest in the WG is on discovery, not this simple upgr= ade process, so we figured we could get these done more quickly while the b= igger discussions are happening.

--Paul Hoffman--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000066103905a5c9811d-- --0000000000007139ca05a5c9810d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCbf+6+hJFo5WrGo7zXKlClKLomhge4WpNd744yPIr5eDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MTYyMDA5MjJaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAFGjuiCJAdpInwEOWiHU8hcpHGif7kvFr49F1t2SpMqhdhU793hkVkwZzKAmdAnBtxFd8Usp+ lhGuZcKiorvkTgbF29A9vq4uVwSUP7JRmERjTV4j/uDHt6eiQXotC2jFpMT8i6t7GT/eKVQOYIla pDOWVhJJg7xBNK53QsAM6UdPIPbZAkHGdpOfLXFr5vyiSu5Orrc6O/gWRTCo5kbuaKVHcd9xR35Q Zsdh/yZhY1nSAlhDPiHR+/uwMmSGVmJuW51AcuOA9J2viJ2oixSjJ4owEOtcZ1ftcKbk0cH6v+J4 uAlx3NAMhOnAMOSzrUBuPGfIBa6BDUCITrHuBkAMUg== --0000000000007139ca05a5c9810d-- From nobody Wed May 20 16:03:58 2020 Return-Path: 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 E5BDC3A0912 for ; Wed, 20 May 2020 16:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 M-FvyCR8Zb7a for ; Wed, 20 May 2020 16:03:48 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.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 9F2CF3A091D for ; Wed, 20 May 2020 16:03:47 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04KMs6jR001853 for ; Wed, 20 May 2020 16:03:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=emg7aQlEVHhUJ+Ofa1deutF0eS/GUnyqJBDdt5hir+Y=; b=OlicbTVmvqzqdQ7882hBvmCtG6UNSTDKGbs2xN8HNdNsqhJegeVgazmm/staiHRSs8eo R1j4JiDW1q44jTfy7MZA7rUGOK6Ngb1PyeUtY+9oEYfJbDpxgnJITJ7iSwPd8xoUPI+W HkX4Rcg/lcWlsuJfRqijsE1ABio7vsWZvdeXVQCvHCUY4OPh3RMg6cmnAtiMdfQJjLOT dk9BXSlnn91Yr13aaUII53Cx5RXyQR1hxzsryr/kSZvaqA2oJ8PMaaiuHSO37+Z1+fh1 vbpQJxhUU7fEoaeBjjA1o4ysJhlxacyidS7RuKhwtexy4yTXXiY4u4djiM0nICxUcvSd ZQ== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 312cuttx48-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 20 May 2020 16:03:46 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QAN00T0BK29FB20@rn-mailsvcp-mta-lapp02.rno.apple.com> for add@ietf.org; Wed, 20 May 2020 16:03:45 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QAN00800JC61300@rn-mailsvcp-mmp-lapp01.rno.apple.com> for add@ietf.org; Wed, 20 May 2020 16:03:45 -0700 (PDT) X-Va-A: X-Va-T-CD: 5daaeb935bbe0e8d25090cf6b04f92b4 X-Va-E-CD: 6adbf5d47afd2c61f6e3c94a3f8e52ac X-Va-R-CD: c014f4c77ddf7cf0554435f897123d8f X-Va-CD: 0 X-Va-ID: 46080845-3b9b-4f93-8c1e-f20443964afa X-V-A: X-V-T-CD: 5daaeb935bbe0e8d25090cf6b04f92b4 X-V-E-CD: 6adbf5d47afd2c61f6e3c94a3f8e52ac X-V-R-CD: c014f4c77ddf7cf0554435f897123d8f X-V-CD: 0 X-V-ID: 27475de7-d016-428c-ae48-a2df6b9018e5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-20_17:2020-05-20, 2020-05-20 signatures=0 Received: from [17.232.191.18] (unknown [17.232.191.18]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QAN004B7K28KW00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for add@ietf.org; Wed, 20 May 2020 16:03:45 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_3FF6EC67-D2CC-4EF3-B935-2FC80E337517" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Message-id: Date: Wed, 20 May 2020 16:03:44 -0700 To: ADD Mailing list X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-20_17:2020-05-20, 2020-05-20 signatures=0 Archived-At: Subject: [Add] New draft: draft-pauly-add-resolver-discovery X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 23:03:57 -0000 --Apple-Mail=_3FF6EC67-D2CC-4EF3-B935-2FC80E337517 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello ADD, We=E2=80=99ve just posted a draft of Adaptive DNS Privacy [1] that=E2=80=99= s scoped down to talk about resolver discovery and designation = mechanisms, both on local networks and over the wider Internet. This = draft is targeted at the focus of the ADD group. https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00 = This covers: - What it means to designate an encrypted resolver - How to discover resolvers using SVCB/HTTPSSVC records - How to validate designation either by validating DNSSEC on these = records, or by performing validation with an HTTPS server - How to advertise a resolver on the local network - How to discover a =E2=80=9Ccompanion=E2=80=9D DoH server to a directly = known resolver Thanks to Tommy Jensen for his additional input on some of the = local/direct resolver bootstrapping. We=E2=80=99ll be publishing other documents that update the behavior for = client algorithms and the use of Oblivious DoH, but we wanted to present = this portion individually as the group discusses how best to discover = resolvers, etc. Best, Tommy [1] Previous, broader version, here: = https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01= --Apple-Mail=_3FF6EC67-D2CC-4EF3-B935-2FC80E337517 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello ADD,

We=E2=80=99ve just posted a draft of Adaptive DNS Privacy [1] = that=E2=80=99s scoped down to talk about resolver discovery and = designation mechanisms, both on local networks and over the wider = Internet. This draft is targeted at the focus of the ADD = group.

https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-= 00

This = covers:
- What it means to designate an encrypted = resolver
- How to discover resolvers using = SVCB/HTTPSSVC records
- How to validate designation = either by validating DNSSEC on these records, or by performing = validation with an HTTPS server
- How to advertise = a resolver on the local network
- How to discover a = =E2=80=9Ccompanion=E2=80=9D DoH server to a directly known = resolver

Thanks = to Tommy Jensen for his additional input on some of the local/direct = resolver bootstrapping.

We=E2=80=99ll be publishing other documents that update the = behavior for client algorithms and the use of Oblivious DoH, but we = wanted to present this portion individually as the group discusses how = best to discover resolvers, etc.

Best,
Tommy

[1] = Previous, broader version, here: https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-pri= vacy-01
= --Apple-Mail=_3FF6EC67-D2CC-4EF3-B935-2FC80E337517-- From nobody Tue May 26 18:03:35 2020 Return-Path: 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 D25753A0C94 for ; Tue, 26 May 2020 18:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JZquFgU_PF3k for ; Tue, 26 May 2020 18:03:32 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 9B81A3A0C8F for ; Tue, 26 May 2020 18:03:31 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id j16so9894875wrb.7 for ; Tue, 26 May 2020 18:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CA2ApZfeRQls2GkE9yVUtmPIYqXBkmsAOYz96zTIevE=; b=LAb0ElGYBbD9AcUBn5FKBVgaUs9lvqiaNFULqN7Vpatj14IwUUiCaJB63RJxLKBkzI Gjfgbk3xO8zrY0ZLtCYw6stjC5oND12YPxvA3V1zMYHIYyCEgfNp8Ofdf9CXOaszgv8N mkdK67uPdECDpNUF5NK++Svf8nXXUO/Ofh2Ldh28nrGu5+sTR/po91aJ+vuugDPUtvuF 3GIQ4JvbR/XPiv2Xc3o3XyWSCn33abGpf/3N92ne6kZGdXeMYGWIUCtDFXlC45FUmeG3 mjnN4rT4V27F5XDlTsbmfRJp4VD9nHrbQnaHW7KjPlOYgVyD1uhrw0tBmxAH9Qsr3Sjh SRhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CA2ApZfeRQls2GkE9yVUtmPIYqXBkmsAOYz96zTIevE=; b=PZ0HYYMELFukHwl9956+uKNI+AdOf3BDRDKxyn0tjqWMzn7jyApok1XKPzfaJ0humB ZbBaPPEFT1JwzEyS1RXCr5VE4XCmfMfJLYdl6+PXWt8jfRI+vXB51eveTrahOIr5d+al hDQKhw+Xh0fjeu+pNeGaUpRCLnUkUmf5O1ZJVrAKKInd+5FfF5192RTjgmYKZ8kGAuuc PgjmLyqcRVlPLAP1HT0/tWEAsza1RpN7WMmulOtZemm1zWenWghe11waiGQ94pLVFLGO c9d8vIzpUZy+HHgBCPwaBmFQozj7OMAjw754Zw9rsjYILYkmnngSE92zyxMh+y9NB447 U+dw== X-Gm-Message-State: AOAM531hC5ZjR7MIujqAug7ywgcm5/93WWOtoe8in0fZN0LMdGrAGrR4 O6dcxldli/iC1kfl2ke4CEBzkLySxxDXUwTkxIjYFH4l72ESpQ== X-Google-Smtp-Source: ABdhPJzM63Z+kyb8pw+DEFN0sI3RIlgCJhdM5/1xpCga90CB1GBhQDKDjbizsZ1odC9wWXblrIQ69ikOPkFdDM+WXZw= X-Received: by 2002:adf:814a:: with SMTP id 68mr22526776wrm.177.1590541409729; Tue, 26 May 2020 18:03:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 26 May 2020 21:03:17 -0400 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c3b50f05a696c7cc" Archived-At: Subject: Re: [Add] New draft: draft-pauly-add-resolver-discovery X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 01:03:34 -0000 --000000000000c3b50f05a696c7cc Content-Type: multipart/alternative; boundary="000000000000ba9a5205a696c7aa" --000000000000ba9a5205a696c7aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for making a simplified form of the proposal to get started. Section 3.1: How do you expect TTLs to work? If the dohuri expires along with the SVCB record that delivered it, is that actually useful? More generally, I think this section is extremely close to https://tools.ietf.org/html/draft-tapril-ns2-00, which is trying to enable recursive->authoritative DoH. We should aim for a unified, or at least coordinated solution to these closely related problems. Section 3.2: > Designated Resolvers that support DoH SHOULD provide a PvD JSON > dictionary available at the well-known PvD URI with the path of the > DoH server's URI template appended. Strictly speaking, "https://example.com{/dns}/foo?bar=3Dbaz" is a valid DoH URI template, but it doesn't have a well-defined path. I think the best option is probably to encode all DoH PvDs on one origin into a single JSON object at a fixed well-known location, with the full template as the top-level key. With dnsZones, is the idea to enable authenticated split-horizon networks? The PvD draft defines "dnsZones" but offers no explanation of its semantics, so I'm having trouble figuring out the intended deployment here. Section 5: I think this is an interesting idea, but to comply with SVCB semantics I would structure this as an SVCB query for dns://resolver.arpa, i.e. at _dns.resolver.arpa. This would resolve to an SVCB RRSet that can enumerate alternative endpoints with different protocols and parameters. (This is again similar to the NS2 proposal.) I don't understand the motivation for using IP hints in this way. Normal A and AAAA records would seem to suffice, and are likely easier to maintain. I don't understand why you require the IP address to appear in the certificate. This would prevent resolvers from directing users to a trusted third party, creates a fragile binding between the insecure and secure resolver deployments (e.g. when changing the resolver's IP address), and rules out this mechanism entirely for home router type configurations. On Wed, May 20, 2020 at 7:04 PM Tommy Pauly wrote: > Hello ADD, > > We=E2=80=99ve just posted a draft of Adaptive DNS Privacy [1] that=E2=80= =99s scoped down > to talk about resolver discovery and designation mechanisms, both on loca= l > networks and over the wider Internet. This draft is targeted at the focus > of the ADD group. > > https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00 > > This covers: > - What it means to designate an encrypted resolver > - How to discover resolvers using SVCB/HTTPSSVC records > - How to validate designation either by validating DNSSEC on these > records, or by performing validation with an HTTPS server > - How to advertise a resolver on the local network > - How to discover a =E2=80=9Ccompanion=E2=80=9D DoH server to a directly = known resolver > > Thanks to Tommy Jensen for his additional input on some of the > local/direct resolver bootstrapping. > > We=E2=80=99ll be publishing other documents that update the behavior for = client > algorithms and the use of Oblivious DoH, but we wanted to present this > portion individually as the group discusses how best to discover resolver= s, > etc. > > Best, > Tommy > > [1] Previous, broader version, here: > https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01 > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000ba9a5205a696c7aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for making a simplified form of the proposal to get= started.

Section 3.1:

How do y= ou expect TTLs to work?=C2=A0 If the dohuri=C2=A0expires along with the SVC= B record that delivered it, is that actually useful?

More generally, I think this section is extremely close to=C2=A0https://tools.ietf.org= /html/draft-tapril-ns2-00, which is trying to enable=C2=A0recursive->= ;authoritative DoH.=C2=A0 We should aim for a unified, or at least coordina= ted solution to these closely related problems.

Se= ction 3.2:
>=C2=A0 =C2=A0Designated Resolvers that support DoH= SHOULD provide a PvD JSON
>=C2=A0 =C2=A0dictionary available at th= e well-known PvD URI with the path of the
>=C2=A0 =C2=A0DoH server= 9;s URI template appended.

Strictly speaking, "https://example.com{/dns}/foo?bar=3Dbaz&quo= t; is a valid DoH URI template, but it doesn't have a well-defined path= .=C2=A0 I think the best option is probably to encode all DoH PvDs on one o= rigin into a single JSON object at=C2=A0a fixed well-known location, with t= he full template as the top-level key.

With dnsZon= es, is the idea to enable authenticated split-horizon networks?=C2=A0 The P= vD draft defines "dnsZones" but offers no explanation of its sema= ntics, so I'm having trouble figuring out the intended deployment here.=

Section 5:
I think this is an inter= esting idea, but to comply with SVCB semantics I would structure this as an= SVCB query for dns://resolver.arpa, i.e.=C2=A0 at _dns.resolver.arpa.=C2= =A0 This would resolve to an SVCB RRSet that can enumerate alternative endp= oints with different protocols and parameters.=C2=A0 (This is again similar= to the NS2 proposal.)

I don't understand the = motivation for using IP hints in this way.=C2=A0 Normal A and AAAA records = would seem to suffice, and are likely easier to maintain.

I don't understand why you require the IP address to appear in = the certificate.=C2=A0 This would prevent resolvers from directing users to= a trusted third party, creates a fragile binding between the insecure and = secure resolver deployments (e.g. when changing the resolver's IP addre= ss), and rules out this mechanism entirely for home router type configurati= ons.

On Wed, May 20, 2020 at 7:04 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> w= rote:
Hello ADD,

We= =E2=80=99ve just posted a draft of Adaptive DNS Privacy [1] that=E2=80=99s = scoped down to talk about resolver discovery and designation mechanisms, bo= th on local networks and over the wider Internet. This draft is targeted at= the focus of the ADD group.

https= ://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00

This covers:
- What it means to designate an encrypted r= esolver
- How to discover resolvers using SVCB/HTTPSSVC records
- How to validate designation either by validating DNSSEC on these= records, or by performing validation with an HTTPS server
- How = to advertise a resolver on the local network
- How to discover a = =E2=80=9Ccompanion=E2=80=9D DoH server to a directly known resolver

Thanks to Tommy Jensen for his additional input on some o= f the local/direct resolver bootstrapping.

We=E2= =80=99ll be publishing other documents that update the behavior for client = algorithms and the use of Oblivious DoH, but we wanted to present this port= ion individually as the group discusses how best to discover resolvers, etc= .
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000ba9a5205a696c7aa-- --000000000000c3b50f05a696c7cc Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCrrupdufifJR9Ut9a+QjE+6mgSi4H93jNcqJuZMdSUBjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MjcwMTAzMzBaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAgb6nuTMAVTO+FEYBtXU8n6fECOmEh4zAFdS1lC5iVGZgTx7BUtbLscyLtBXG8nD7wzd88KW4 gmESLQaMPdfc+fkZzh941EBIApkhdkvgB9OlT/yhEZuvthco2PmJsZWr6w0sV7VooFKpDJ81Hsll Zx1s6bDp+Xcl/h5rzBZhWreEsgKKoz/WodmIuJsnfFWXagFvCT5kUsv/BxCeu9J9/RpV7CyoN+wZ Cz3AS9B0XxKq2KtNOJXiJPSBG2SyJAIYHp3AiRMohhcfD2x9s3X7j5DCSUdokqLSqi/e8z2aaguX bc96a0/3IwAcfWSAAKBZoeXyualaItxlZfJWlHDnug== --000000000000c3b50f05a696c7cc-- From nobody Wed May 27 19:51:12 2020 Return-Path: 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 C4D4C3A0B38 for ; Wed, 27 May 2020 19:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 VZCW3ktnrHWR for ; Wed, 27 May 2020 19:51:01 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650116.outbound.protection.outlook.com [40.107.65.116]) (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 4869C3A0B37 for ; Wed, 27 May 2020 19:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qly7TeVQVz9vj9+DOJnTrlRDlAcnkUkGBN8BSkrOMj9igAtYy4s4YkstwuWlbaYIftcOmqsKn42334JJz71JVLqfS5jM/vRcCBuwko789LB46EwYxFhqoxh/WLrMDzLb+ar0HwUVYu7kOnMHzfC3fkukt46/AUd/F68uaHODie85420R97gfTU0hGTZ0Km51sc8viAAU/J2OIkpwTh5hDYR5x1KqcRcUU29Wl4DCSjUu+5BgYyeyOB/fIV28DV+gmqcvcOR9vbU9knIh0PlajuSEcne96HBlLE+a3hhXoEbOss0kLXalvBZmJv99DJ+BNI4AcMSpp3D26Kz+ZSfZCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gsniJZb2lL8BubZh9eAcmnWF8QxzyBdGupwTLomKwlo=; b=NCPp+Gm76IInk/SBDXZqVpW4AqO9EK8dkswvovY9KT9uLjUTOgv/0yFv5Nda3y2XKQi1ZXsTBsKjNcf73KAVUN49Xsb68deX4XI06DisVdljNznb95EjRvd6ysnWkk9gMHRWv/JNkv/bLsIeNRJYXWoHqJP/l5KWQbumEMZg2SiN4JBtmVuIRycF2+uF2cHrM7p7I5Cxjtyuyj/2u5d7sayZ2NjQ2gvz579shrAwkgKUziKVyOLnTgyRfY15h9dDbYkeHDH6XDNKSkuiP9lMAieeIFQUHY7jglerFDNCCGyfv8aH+nIjiT5BUYTtWpqk2zZRjFCyR3xBSutXs8UKZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gsniJZb2lL8BubZh9eAcmnWF8QxzyBdGupwTLomKwlo=; b=P9kQjRB28UE0ynacztZ45QoEql4CWdczby+NwCBvnhkt8MzYiQuIyBSdBa635bFFZTQiIBls0sA64fVaH2f7A2tk7D18rbX186TpiEqzVzP7nhMWT/Ymc4/ll9JZY3Qu4Io76EdG2MNoHw9coybqlk9Qnd2MEhHcd4EZyE+qAEs= Received: from BY5PR00MB0775.namprd00.prod.outlook.com (2603:10b6:a03:1d1::12) by BYAPR00MB0549.namprd00.prod.outlook.com (2603:10b6:a03:101::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3084.0; Thu, 28 May 2020 02:49:18 +0000 Received: from BY5PR00MB0775.namprd00.prod.outlook.com ([fe80::9c5c:f7d2:df8b:ac6f]) by BY5PR00MB0775.namprd00.prod.outlook.com ([fe80::9c5c:f7d2:df8b:ac6f%6]) with mapi id 15.20.3087.000; Thu, 28 May 2020 02:49:18 +0000 From: Tommy Jensen To: Ben Schwartz , Tommy Pauly CC: ADD Mailing list Thread-Topic: [EXTERNAL] Re: [Add] New draft: draft-pauly-add-resolver-discovery Thread-Index: AQHWM8Ks0qPIiJjOBkGKd5zMVdtG76i8mbua Date: Thu, 28 May 2020 02:49:18 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-28T02:49:16.003Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:a080:aff0:dde7:102f:faf5:d45d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 17fd8c48-5274-497a-fc00-08d802b1b75d x-ms-traffictypediagnostic: BYAPR00MB0549: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QjY0zHeC7NvHBoBXLdm7OFL7zBARRYg6M+xGXjjg5wYFvTjeWm/stWOdczCC4gSzfxwZGc9VI6zKYJph7+ck5gJR2IAf1Yr0hckLXqPPw6V+dFkWcFxDrdoDjCLKuwQt21mxyAQHABdIghpNciSMq0716l4KcDL1NuzRVZckHWT0YlMe9YSXlmwM0d+XNEY+mjWGMAF1tOLbF/x2M7YRi7eSrcC02OULqG33+9NTZZeGlPsgqUmCba2iJRZxGwQFE6Wy+hAILVioKgbsbrSo7qdzPGxeNh5BqA6wBU3p1gRf4VZJFj/eY+9kQ383sKlSEx6KutUTCWuu2qUYS32/uFHYamjcBv5Ow/q68OqTeiO/z10q3oUhNeuf3HY9lgGzOS1QRd3Z7FNnYaemzzUdNw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0775.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(346002)(396003)(39860400002)(136003)(66556008)(66446008)(2906002)(53546011)(6506007)(4326008)(8990500004)(9686003)(6512007)(110136005)(76116006)(186003)(6486002)(71200400001)(5660300002)(82960400001)(83380400001)(82950400001)(52536014)(64756008)(66946007)(316002)(166002)(8676002)(966005)(10290500003)(66574014)(86362001)(33656002)(8936002)(19627405001)(478600001)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: hHSmUCmomeuqL48TZOixyR1u5gBCJcOs8o2y1bUb7baa9MfouiDUaaE5tr4ppYKKfOXOuHdNQCR8ZpyDnDhCrkCDMynU+kC5/WSXKefQCwDkxDn5H7usVbiF/M1KgYFm9CTI+Mk+LdoohqJ7A3rKPKtijRKBFQe9hZtIAz9hapoDfCTsKfPIZ6u3D7xfOPKRx5tbDwKFJP1JWFkH/UWVIQvs2l639wabkqSFzlHEq8M1fndPyuAvK0hk19i5iqW7Y1HXHiIKUin2yR7NEc8njQHKOHLsQyzwyXP+J/O2YXK0RxNtkYV77mgoXahmAPaTtRlynazgP3PkfQgm0OK6SqVplIQjEiBtiPFQNVnyEyVYU9mQS6KaqUbA8O8fxkelETbDEnh2Z8S9+ukAX7kNSgkK/omyq3xWmRHvN5Nn/QtcVkEzBBA/1gnKhj9T7EY4B1CBDd3t8YSPgOWWvYV1sYhpGd05X/1FjGvdMaT7Z08T63+Xm021sd1XqWQ9KiBLvMd9Cv+UBNU/KfbVm6v7pQnjJW6kyYuZoqNhr50Law8ikVooMN3akjt+i3U2Kr7x x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB077979DCC04573846A893D87FAB10CH2PR00MB0779namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0775.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17fd8c48-5274-497a-fc00-08d802b1b75d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 02:49:18.0771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bPon6xE1Dt5S3jVQz5/WwX7xjyfILUbbW/HF5HWQYlGwfQ6pUCaJsb6rNfpe+1Tnt/e++YGexYdPjvaLQ6+I3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0549 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: New draft: draft-pauly-add-resolver-discovery X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 02:51:11 -0000 --_000_CH2PR00MB077979DCC04573846A893D87FAB10CH2PR00MB0779namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey Ben, Thank you for your feedback! For Section 5: > I would structure this as an SVCB query for dns://resolver.arpa, i.e. at= _dns.resolver.arpa. This makes sense; I'll give it more thought. > I don't understand the motivation for using IP hints in this way. Normal= A and AAAA records would seem to suffice, and are likely easier to maintai= n. The thinking here was the multiple record case. If there are two SVCB recor= ds returned to designate two DoH servers that are equivalent, then having t= he hints in the record itself makes the mapping more clear than sending bac= k two As and two AAAAs along with some mapping logic. Additionally, I think= the named parameter context helps keep it future proof in case future vers= ions specify a second use of IP addresses within the record where A/AAAA wo= uld be ambiguous. > I don't understand why you require the IP address to appear in the certif= icate. This would prevent resolvers from directing users to a trusted thir= d party, This is very much by design. As a stub resolver, I cannot tell the differen= ce between "classic DNS server foo recommends DoH server bar" and "classic = DNS server foo recommends DoH server bad-actor" thanks to a MitM. If the IP= addresses of both resolvers aren't in the DoH server cert, then there isn'= t a way to validate the claim made over classic DNS that the DoH server can= serve the same needs the classic resolver can. With this requirement in pl= ace, an on-path attacker could still prevent upgrade to DoH by dropping pac= kets (as with any DoH bootstrap starting only with classic DNS), but couldn= 't redirect stubs to a rogue DoH server. > creates a fragile binding between the insecure and secure resolver deploy= ments (e.g. when changing the resolver's IP address), Fair point. This does place a new burden on resolver admins. > and rules out this mechanism entirely for home router type configurations= . Not entirely, as not all ISPs hand out RFC1918 addresses. However, if the r= outer is advertising RFC1918 addresses for DNS use, then yes, this mechanis= m won't help. Given ownership of an RFC1918 address isn't verifiable like a= public address is, I think it would be preferable for the stub resolver to= get the encrypted DNS configuration directly from the same source as it wo= uld get the classic DNS address today, such as through PvDs. Thanks, Tommy ________________________________ From: Add on behalf of Ben Schwartz Sent: Tuesday, May 26, 2020 6:03 PM To: Tommy Pauly Cc: ADD Mailing list Subject: [EXTERNAL] Re: [Add] New draft: draft-pauly-add-resolver-discovery Thanks for making a simplified form of the proposal to get started. Section 3.1: How do you expect TTLs to work? If the dohuri expires along with the SVCB = record that delivered it, is that actually useful? More generally, I think this section is extremely close to https://tools.ie= tf.org/html/draft-tapril-ns2-00, which is = trying to enable recursive->authoritative DoH. We should aim for a unified= , or at least coordinated solution to these closely related problems. Section 3.2: > Designated Resolvers that support DoH SHOULD provide a PvD JSON > dictionary available at the well-known PvD URI with the path of the > DoH server's URI template appended. Strictly speaking, "https://example.com{/dns}/foo?bar=3Dbaz" is a valid DoH= URI template, but it doesn't have a well-defined path.. I think the best = option is probably to encode all DoH PvDs on one origin into a single JSON = object at a fixed well-known location, with the full template as the top-le= vel key. With dnsZones, is the idea to enable authenticated split-horizon networks? = The PvD draft defines "dnsZones" but offers no explanation of its semantic= s, so I'm having trouble figuring out the intended deployment here. Section 5: I think this is an interesting idea, but to comply with SVCB semantics I wo= uld structure this as an SVCB query for dns://resolver.arpa, i.e. at _dns.= resolver.arpa. This would resolve to an SVCB RRSet that can enumerate alte= rnative endpoints with different protocols and parameters. (This is again = similar to the NS2 proposal.) I don't understand the motivation for using IP hints in this way. Normal A= and AAAA records would seem to suffice, and are likely easier to maintain. I don't understand why you require the IP address to appear in the certific= ate. This would prevent resolvers from directing users to a trusted third = party, creates a fragile binding between the insecure and secure resolver d= eployments (e.g. when changing the resolver's IP address), and rules out th= is mechanism entirely for home router type configurations. On Wed, May 20, 2020 at 7:04 PM Tommy Pauly > wrote: Hello ADD, We=92ve just posted a draft of Adaptive DNS Privacy [1] that=92s scoped dow= n to talk about resolver discovery and designation mechanisms, both on loca= l networks and over the wider Internet. This draft is targeted at the focus= of the ADD group. https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00 This covers: - What it means to designate an encrypted resolver - How to discover resolvers using SVCB/HTTPSSVC records - How to validate designation either by validating DNSSEC on these records,= or by performing validation with an HTTPS server - How to advertise a resolver on the local network - How to discover a =93companion=94 DoH server to a directly known resolver Thanks to Tommy Jensen for his additional input on some of the local/direct= resolver bootstrapping. We=92ll be publishing other documents that update the behavior for client a= lgorithms and the use of Oblivious DoH, but we wanted to present this porti= on individually as the group discusses how best to discover resolvers, etc.= . Best, Tommy [1] Previous, broader version, here: https://tools.ietf.org/html/draft-paul= y-dprive-adaptive-dns-privacy-01 -- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add --_000_CH2PR00MB077979DCC04573846A893D87FAB10CH2PR00MB0779namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hey Ben,

Thank you for your feedback! For Section 5:

> I would structure this as an SVCB query for dns://resolver.arpa, i.e.  = at _dns.resolver.arpa.
I don't understand the motivation for using IP hints in this way.  Norm= al A and AAAA records would seem to suffice, and are likely easier to maint= ain.

The thinking here was the multiple record case. If there are two SVCB records = returned to designate two DoH servers that are equivalent, then having the = hints in the record itself makes the mapping more clear than sending back t= wo As and two AAAAs along with some mapping logic. Additionally, I think the named parameter context helps kee= p it future proof in case future versions specify a second use of IP addres= ses within the record where A/AAAA would be ambiguous.

> I don't understand why you require the IP address to appear in the certifica= te.  This would prevent resolvers from directing users to a trusted th= ird party,

This is very much by design. As a stub resolver, I cannot tell the difference b= etween "classic DNS server foo recommends DoH server bar" and &qu= ot;classic DNS server foo recommends DoH server bad-actor" thanks to a= MitM. If the IP addresses of both resolvers aren't in the DoH server cert, then there isn't a way to validate the claim made = over classic DNS that the DoH server can serve the same needs the classic r= esolver can. With this requirement in place, an on-path attacker could stil= l prevent upgrade to DoH by dropping packets (as with any DoH bootstrap starting only with classic DNS), but co= uldn't redirect stubs to a rogue DoH server.

<= span style=3D"font-size: 15px;">> creates a fragile binding between the insecure and secure resolver deployments (e.= g. when changing the resolver's IP address),
<= span style=3D"font-size: 15px;">
<= span style=3D"font-size: 15px;">Fair point. This does place a new burden on= resolver admins.
<= span style=3D"font-size: 15px;">
<= span style=3D"font-size: 15px;">> and rules out this mechanism entirely for home router type configurations.
<= span style=3D"font-size: 15px;">
<= span style=3D"font-size: 15px;">Not entirely, as not all ISPs hand out RFC1= 918 addresses. However, if the router is advertising RFC1918 addresses for = DNS use, then yes, this mechanism won't help. Given ownership of an RFC1918 address isn't verifiable like a public= address is, I think it would be preferable for the stub resolver to get th= e encrypted DNS configuration directly from the same source as it would get= the classic DNS address today, such as through PvDs.

Thanks,
Tommy
From: Add <add-bounces@i= etf.org> on behalf of Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.= org>
Sent: Tuesday, May 26, 2020 6:03 PM
To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
Cc: ADD Mailing list <add@ietf.org>
Subject: [EXTERNAL] Re: [Add] New draft: draft-pauly-add-resolver-di= scovery
 
Thanks for making a simplified form of the proposal to get= started.

Section 3.1:

How do you expect TTLs to work?  If the dohuri expires along= with the SVCB record that delivered it, is that actually useful?

More generally, I think this section is extremely close to https://tools.ietf.org/html/draft-tapril-ns2-00, which is trying to enable recursive->authoritative DoH.  We s= hould aim for a unified, or at least coordinated solution to these closely = related problems.

Section 3.2:
>   Designated Resolvers that support DoH SHOULD provide = a PvD JSON
>   dictionary available at the well-known PvD URI with the pa= th of the
>   DoH server's URI template appended.

Strictly speaking, "https://example.c= om{/dns}/foo?bar=3Dbaz" is a valid DoH URI template, but it doesn't have a well-defined path..&nbs= p; I think the best option is probably to encode all DoH PvDs on one origin= into a single JSON object at a fixed well-known location, with the fu= ll template as the top-level key.

With dnsZones, is the idea to enable authenticated split-horizon netwo= rks?  The PvD draft defines "dnsZones" but offers no explana= tion of its semantics, so I'm having trouble figuring out the intended depl= oyment here.

Section 5:
I think this is an interesting idea, but to comply with SVCB semantics= I would structure this as an SVCB query for dns://resolver.arpa, i.e. = ; at _dns.resolver.arpa.  This would resolve to an SVCB RRSet that can= enumerate alternative endpoints with different protocols and parameters.  (This is again similar to the NS2 proposal= .)

I don't understand the motivation for using IP hints in this way. = ; Normal A and AAAA records would seem to suffice, and are likely easier to= maintain.

I don't understand why you require the IP address to appear in the cer= tificate.  This would prevent resolvers from directing users to a trus= ted third party, creates a fragile binding between the insecure and secure = resolver deployments (e.g. when changing the resolver's IP address), and rules out this mechanism entirely for home= router type configurations.

On Wed, May 20, 2020 at 7:04 PM Tom= my Pauly <tpauly=3D40apple= .com@dmarc.ietf.org> wrote:
Hello ADD,

We=92ve just posted a draft of Adaptive DNS Privacy [1] that=92s scope= d down to talk about resolver discovery and designation mechanisms, both on= local networks and over the wider Internet. This draft is targeted at the = focus of the ADD group.

https= ://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00

This covers:
- What it means to designate an encrypted resolver
- How to discover resolvers using SVCB/HTTPSSVC records
- How to validate designation either by validating DNSSEC on these rec= ords, or by performing validation with an HTTPS server
- How to advertise a resolver on the local network
- How to discover a =93companion=94 DoH server to a directly known res= olver

Thanks to Tommy Jensen for his additional input on some of the local/d= irect resolver bootstrapping.

We=92ll be publishing other documents that update the behavior for cli= ent algorithms and the use of Oblivious DoH, but we wanted to present this = portion individually as the group discusses how best to discover resolvers,= etc..

Best,
Tommy

--
Add mailing list
Add@ietf.org
https://www.ietf.org/= mailman/listinfo/add
--_000_CH2PR00MB077979DCC04573846A893D87FAB10CH2PR00MB0779namp_-- From nobody Thu May 28 03:19:55 2020 Return-Path: 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 08D033A0C2F for ; Thu, 28 May 2020 03:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 Llsvohi4tXFn for ; Thu, 28 May 2020 03:19:50 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 9A9893A0C24 for ; Thu, 28 May 2020 03:19:50 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id y17so24829880ilg.0 for ; Thu, 28 May 2020 03:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6KXQTafF35YOXiwyqTQTu2XIy6EX7d4XgdEkjkYL0QQ=; b=f9Cq0RbZufhPcPLsZOrJ4GZ0TRqxmaPA9v84gCD8QSoKhV/Z6+quKSff/ZiS8R89/S D2BkW4g9iS9hkmxKn2vrI07Vy/rUOZs3KUEmSrqU1vKvpkYpUjH6UUjbpCYr9xPpCEqX SUPVg0EqU3ik68YI3+5wpJ3Z7qcQk51EgAjktVdwiGvaFhsXf1c2v7XcWQjFJ8fh+hLx r65WoolxIYZfHZTs7SS35S1hAZxptG6mnaTQ7IRvzwS3cEprbWto+R2YjVlyCXTcg4NU LpY3ntyLBLizEJhI967Ox+B690pktTpZ406T7N44fZJJTbU7GHHs00onaHz4/MxGUbn1 jREA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6KXQTafF35YOXiwyqTQTu2XIy6EX7d4XgdEkjkYL0QQ=; b=j1YooYQAyA3mo3epJMxFYyjhjObQbtcXSyG8pSmqSqJnFLdvP6uPiLTRAKw2T3R0v4 r25V1AclRRF+LhiHpJ/KugrYekyy9tZvAVP2s7dfpy0OqWppVfBv2mNSi7PGJIIO1GdR mI4+B1xV5X8GDBdngiwCejrnJDoY/BL6ZIJ9n0cYnFCrb2G19ZeAr4H7TaQzcRaHJzgm +fPX/6EXEF4XVEDACKxojjX6OEqT/G35qZLvxNQD9igpKdCwdpkLuxjjlC9pl4yrraYj ZFfSHIXqxYCEJSePjQ9ongaoSTAgip4c966eb67xJK/iOBBQS//OzYud+lLhWAHxbPdY 7rEw== X-Gm-Message-State: AOAM533B0r4njigJAqntJ96cvYiSJ/qHniTBsBOfRvo+mvlNkeWu7V76 QTxUv2s84cZjkU7NeQZjA5Xcxf1yQgeghH6AFUsUr0Le X-Google-Smtp-Source: ABdhPJwRo/uis3Kx7cW7EsOQXAMkOfmGa/7PHU637+oKWLgt+62x8//2TEpWDDmt2i5QCEB0JUnmARMYAwjFJvSzIN8= X-Received: by 2002:a92:400e:: with SMTP id n14mr2157727ila.300.1590661189652; Thu, 28 May 2020 03:19:49 -0700 (PDT) MIME-Version: 1.0 References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> In-Reply-To: <159064546659.30784.12927519685709906985@ietfa.amsl.com> From: tirumal reddy Date: Thu, 28 May 2020 15:49:38 +0530 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000002ad48605a6b2ab1d" Archived-At: Subject: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 10:19:53 -0000 --0000000000002ad48605a6b2ab1d Content-Type: text/plain; charset="UTF-8" Hi all, We prepared an updated version of https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-02 to address comments from Neil. It discusses how a DNS client can authenticate it is connecting to a DoH/DoT server hosted by a specific organization (e.g., ISP). We now rely on I-D.pp-add-resinfo to retrieve the Policy Assertion Token (PAT). Comments are welcome. Cheers, -Tiru ---------- Forwarded message --------- From: Date: Thu, 28 May 2020 at 11:27 Subject: New Version Notification for draft-reddy-add-server-policy-selection-02.txt To: Dan Wing , Mohamed Boucadair < mohamed.boucadair@orange.com>, Tirumaleswar Reddy.K , Michael C. Richardson A new version of I-D, draft-reddy-add-server-policy-selection-02.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-add-server-policy-selection Revision: 02 Title: DNS Server Selection: DNS Server Information with Assertion Token Document date: 2020-05-27 Group: Individual Submission Pages: 23 URL: https://www.ietf.org/internet-drafts/draft-reddy-add-server-policy-selection-02.txt Status: https://datatracker.ietf.org/doc/draft-reddy-add-server-policy-selection/ Htmlized: https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-add-server-policy-selection Diff: https://www.ietf.org/rfcdiff?url2=draft-reddy-add-server-policy-selection-02 Abstract: The document defines a mechanism that allows communication of DNS resolver information to DNS clients for use in server selection decisions. In particular, the document defines a mechanism for a DNS server to communicate its filtering policy and privacy statement URL to DNS clients. This information is cryptographically signed to attest its authenticity. Such information is used for the selection of DNS resolvers. Typically, evaluating the DNS privacy statement, filtering policy, and the signatory, DNS clients with minimum human intervention can select the DNS server that best supports the user's desired privacy and filtering policy. This assertion is useful for encrypted DNS (e.g., DNS-over-TLS and DNS-over-HTTPS) servers that are either public resolvers or are discovered in a local network. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000002ad48605a6b2ab1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

We prepared an updated version of https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-02= to address comments from Neil. It discusses how a DNS client can authentic= ate it is connecting to a DoH/DoT server hosted by a specific organization = (e.g., ISP). We now rely on I-D.pp-add-resinfo to retrieve the Policy Asser= tion Token (PAT).

Comments are welcome.

Cheers,
-Tiru
=
-= --------- Forwarded message ---------
From: <internet-drafts@ie= tf.org>
Date: Thu, 28 May 2020 at 11:27
Subject: New Ve= rsion Notification for draft-reddy-add-server-policy-selection-02.txt
To= : Dan Wing <= dwing-ietf@fuggles.com>, Mohamed Boucadair <mohamed.boucadair@orange.com>, Tirumaleswar Reddy.K <kondtir@gmail.com>, Michael C. Richardson <mcr+ietf@sandelman.ca= >



A new version of I-D, draft-reddy-add-server-policy-selection-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-add-server-policy= -selection
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS Server Selection: DNS Server I= nformation with Assertion Token
Document date:=C2=A0 2020-05-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 23
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-red= dy-add-server-policy-selection-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-reddy-add-server-polic= y-selection/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-0= 2
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-reddy-add-server-p= olicy-selection
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-add= -server-policy-selection-02

Abstract:
=C2=A0 =C2=A0The document defines a mechanism that allows communication of = DNS
=C2=A0 =C2=A0resolver information to DNS clients for use in server selectio= n
=C2=A0 =C2=A0decisions.=C2=A0 In particular, the document defines a mechani= sm for a DNS
=C2=A0 =C2=A0server to communicate its filtering policy and privacy stateme= nt URL
=C2=A0 =C2=A0to DNS clients.=C2=A0 This information is cryptographically si= gned to
=C2=A0 =C2=A0attest its authenticity.=C2=A0 Such information is used for th= e selection
=C2=A0 =C2=A0of DNS resolvers.=C2=A0 Typically, evaluating the DNS privacy = statement,
=C2=A0 =C2=A0filtering policy, and the signatory, DNS clients with minimum = human
=C2=A0 =C2=A0intervention can select the DNS server that best supports the = user's
=C2=A0 =C2=A0desired privacy and filtering policy.

=C2=A0 =C2=A0This assertion is useful for encrypted DNS (e.g., DNS-over-TLS= and
=C2=A0 =C2=A0DNS-over-HTTPS) servers that are either public resolvers or ar= e
=C2=A0 =C2=A0discovered in a local network.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--0000000000002ad48605a6b2ab1d-- From nobody Thu May 28 07:32:10 2020 Return-Path: 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 BD9133A0F0C for ; Thu, 28 May 2020 07:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=open-xchange.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 kD9dRpzEPVjd for ; Thu, 28 May 2020 07:32:05 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 789693A0F04 for ; Thu, 28 May 2020 07:32:05 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id 04EEC6A315; Thu, 28 May 2020 16:32:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1590676321; bh=L4e5GhsgVwclxeu125iFxB7R6UfVODlhPyyUkK/J3Nk=; h=Date:From:To:In-Reply-To:References:Subject:From; b=1rCMB+XdzmdxdFuU7Wg+xiLQzWCDD3+WUTCKyUuQjbpqzkyfhjANELa8nSR9YZxNb PsJkR3YK/Z1Y/q5qf4aGHSzVyFwnSFioe3wHtbrDFfQ94mNzXtF80SCog3eF99UclO 4YNQqaGa79SXWL1aOyaKcAkw9dg4dJdOTTdPOON68zY7a+9QgZDM3bYGthzag7K76M 57Nz12K6EURPE+nwRZ12DQp+FGE6RD3z9dEN2hvnqznLnhpd8MYhX7rd27Jx5JuDcU 3ApwTIT8BkwlwM+yvTdQzjDUDeH9zR3wDirpjsw5jPZcBFVGmDM/3FLWdztg/0HNLs x22HmIhL6ADOA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id E7F5D3C0310; Thu, 28 May 2020 16:32:00 +0200 (CEST) Date: Thu, 28 May 2020 16:32:00 +0200 (CEST) From: Vittorio Bertola To: tirumal reddy , ADD Mailing list Message-ID: <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> In-Reply-To: References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6606_8825202.1590676320781" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 14:32:08 -0000 ------=_Part_6606_8825202.1590676320781 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 28/05/2020 12:19 tirumal reddy ha scritto: > > > Hi all, > > We prepared an updated version of https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-02 to address comments from Neil. It discusses how a DNS client can authenticate it is connecting to a DoH/DoT server hosted by a specific organization (e.g., ISP). We now rely on I-D.pp-add-resinfo to retrieve the Policy Assertion Token (PAT). > > Comments are welcome. > Thanks for this work. I think we need feedback by client developers that would consume this information. You might need something more detailed or specific to express the server's policies; for example, machine-readable indication of authentication support, logging policies, or fine-grained description of filtering policies could be used by clients that want to standardize their analysis and presentation of server features. It's good to have an extension mechanism, but there would still be the need for agreement on what the new claims mean. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_6606_8825202.1590676320781 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 28/05/2020 12:19 tirumal reddy <kondtir@gmail.com> ha scritto:


Hi all,

We prepared an updated version of https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-02 to address comments from Neil. It discusses how a DNS client can authenticate it is connecting to a DoH/DoT server hosted by a specific organization (e.g., ISP). We now rely on I-D.pp-add-resinfo to retrieve the Policy Assertion Token (PAT).

Comments are welcome.
Thanks for this work. I think we need feedback by client developers that would consume this information. You might need something more detailed or specific to express the server's policies; for example, machine-readable indication of authentication support, logging policies, or fine-grained description of filtering policies could be used by clients that want to standardize their analysis and presentation of server features. It's good to have an extension mechanism, but there would still be the need for agreement on what the new claims mean.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_6606_8825202.1590676320781-- From nobody Fri May 29 09:43:18 2020 Return-Path: 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 B6C1A3A0DAD for ; Fri, 29 May 2020 09:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 BoF6BHK456bP for ; Fri, 29 May 2020 09:43:14 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 C22E33A0DA8 for ; Fri, 29 May 2020 09:43:14 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id p15so1344330qvr.9 for ; Fri, 29 May 2020 09:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+/KUfZuNzDkSOUHYCE4ZYrvKCf6DnUoDK33t5dEQRtE=; b=sU5SfJHgA/a7DQUgjYpu0Ww/1G2s/sfm0QWbolkVN1geA0msAcs+mFn7Tj3XQtA/Id gMqZo/PF+5XhNxG4YxIiRr8v20IuNbSkr2CyHqHW3aZhepdWTg+4Pg9lg2gTTOW4iSO2 OK4nl5eHJ2kyXauM4bkkVwPpkM69TcK9DeKZdq2TjdmzPCXT95r6xDwp2a5f8CIfB9fO Gj7bTpViuTwW5O1du4BWRA0MYLJh9UXPykPMGGtdSoAJcjX7kqNXBntiD31N2vcYdjNg W39v+BpDNQ77vrxxIusbyw2X1X5eQCN4H4AJtS4yvAeRygtgZNIlus6fZLqXN443qE92 ZzVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+/KUfZuNzDkSOUHYCE4ZYrvKCf6DnUoDK33t5dEQRtE=; b=NfUSviaTYMdnTcLcU5g/5I94sSIZb8ka3+KBODJqWI8gWa0dhvzE+IFJU4Jx93gs4p qWNGQt6SuyaGl0OP058FfaRTosvGpek4DZoD7eP41w9ygvGdFvqpx3CP9DRdj9h4ysi5 YTGXUNoPNieUmKL3Yc046ImvQvtMpHI961vuBHkl9J5VvxkSP553kp1eFN3GjCDHjYac qqTRJNiInVHPw0o9Fna+VV4WAO4BN5h82f0/5yDPlukZH8mXuj0AvrvpFYla4zc2wC3S kktcsZW6bQ1Pl45x4Br+53Bu5zftPp8/k8sHhuChNaNVcpH8U/XcMj2NKLvJbnADFzfL CU2g== X-Gm-Message-State: AOAM531Q8rhvP0ypkmehO+ZI5CPvDXMVlXNKaOeQY6yKnFTF/idVO3bR C6Yxt2jxoKLg71HoCC+04NRvm6lX7RnQI0VyNlvuFoMW X-Google-Smtp-Source: ABdhPJxzGwo0zw55fS0eX5edTv4OQXW+bA3v4AnZeerN82UYBLEqYEmuJeWb5A65yViDgJEq/jLmiOOlCq1Z4gfJERw= X-Received: by 2002:a0c:b45b:: with SMTP id e27mr3571643qvf.85.1590770593496; Fri, 29 May 2020 09:43:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Chris Box (BT)" Date: Fri, 29 May 2020 17:43:02 +0100 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000250aba05a6cc2457" Archived-At: Subject: Re: [Add] New draft: draft-pauly-add-resolver-discovery X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 16:43:17 -0000 --000000000000250aba05a6cc2457 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks to the authors for this new draft. Having now read it, I'd like to raise a few points for discussion. *Section 3 Designated Resolvers* This states Note that clients MUST NOT accept designations for effective top- level domains (eTLDs), such as ".com". This can be hard to define, and I know there's a history of problems in this space, so it feels like it requires a normative reference. Would this be the best one? https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#termi= nology If so, should it be renamed from "eTLDs" to "Public Suffixes"? *3.2 Additional Designation with PvD JSON* Names that are listed in the "dnsZones" key in the JSON dictionary indicate other names that designate the resolver. For each of those domains, clients SHOULD issue an SVCB query to the DoH resolver. I would prefer to have some guidance in here about the number of dnsZones that are considered reasonable to list (10? 20? 50?). And also clarify that clients can form their own view on which of these should result in a SVCB query. Perhaps the client could use the knowledge that SVCB answers might be cached by its own OS and deal with those first, before then issuing external queries for up to "n" zones that it thinks are the most likely to be required? And perhaps we could guide the creator of the PvD that they should return dnsZones ordered by likely popularity, from most to least? *3.3 Mutual Confirmation with PvD JSON* Clients MUST validate the resolver designation by checking a resource hosted by the name indicated in "trustedNames". The client first issues an HTTP GET request by appending "/.well-known/pvd" to the trusted name, using the "https" scheme. If a Pvd claims to be designated for 10 dnsZones, and adds that all 10 are also trustedZones, what should the client do? It sounds like it should send 10 SVCB queries, but if they are not validly signed, it should then follow up with 10 GETs (each of which may in turn need A/AAAA queries). Or do you envisage a different algorithm? *References to whitelisting* Section 6.3: Clients can also choose to only whitelist DoH servers that are associated with many names. Section 8: Such risk can be mitigated by further restricting the list of resolvers that are whitelisted for direct use based on client policy. It feels odd that whitelisting is mentioned in this draft but there is no narrative on how it might work, and what it would need to take into consideration. Do you intend to cover this in the separate document that updates client behaviour? Thanks, Chris On Thu, 21 May 2020 at 00:04, Tommy Pauly wrote: > Hello ADD, > > We=E2=80=99ve just posted a draft of Adaptive DNS Privacy [1] that=E2=80= =99s scoped down > to talk about resolver discovery and designation mechanisms, both on loca= l > networks and over the wider Internet. This draft is targeted at the focus > of the ADD group. > > https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00 > > This covers: > - What it means to designate an encrypted resolver > - How to discover resolvers using SVCB/HTTPSSVC records > - How to validate designation either by validating DNSSEC on these > records, or by performing validation with an HTTPS server > - How to advertise a resolver on the local network > - How to discover a =E2=80=9Ccompanion=E2=80=9D DoH server to a directly = known resolver > > Thanks to Tommy Jensen for his additional input on some of the > local/direct resolver bootstrapping. > > We=E2=80=99ll be publishing other documents that update the behavior for = client > algorithms and the use of Oblivious DoH, but we wanted to present this > portion individually as the group discusses how best to discover resolver= s, > etc. > > Best, > Tommy > > [1] Previous, broader version, here: > https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01 > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000250aba05a6cc2457 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to the authors for this new draft. Having now = read it, I'd like to raise a few points for discussion.

<= /div>
Section 3 Designated Resolvers
This states

=C2=A0=C2=A0 Note that clients MUST NOT accept designations for effective top-
=C2=A0=C2=A0 level domains (eTLDs), such as ".com".

This can be hard to define, and I know there's a history of = problems in this space, so it feels like it requires a normative reference.=
Would this be the best one? https://httpwg.or= g/http-extensions/draft-ietf-httpbis-rfc6265bis.html#terminology
If = so, should it be renamed from "eTLDs" to "Public Suffixes&qu= ot;?

3.2 Additional Designation with PvD JSON
=C2=A0=C2=A0 Names that = are listed in the "dnsZones" key in the JSON dictionary
=C2=A0= =C2=A0indicate other names that designate the resolver.=C2=A0 For each of = those
=C2=A0 =C2=A0domains, clients SHOULD issue an SVCB query to the Do= H resolver.

I would prefer to have some gui= dance in here about the number of dnsZones that are considered reasonable t= o list (10? 20? 50?). And also clarify that clients can form their own view= on which of these should result in a SVCB query.

= Perhaps the client could use the knowledge that SVCB answers might be cache= d by its own OS and deal with those first, before then issuing external que= ries for up to "n" zones that it thinks are the most likely to be= required? And perhaps we could guide the creator of the PvD that they shou= ld return dnsZones ordered by likely popularity, from most to least?
<= div>
3.3 Mutual Confirmation with PvD JSON
<= span style=3D"font-family:monospace">=C2=A0=C2=A0 Clients MUST validate the= resolver designation by checking a resource
=C2=A0 =C2=A0hosted by the = name indicated in "trustedNames".=C2=A0 The client first
=C2= =A0 =C2=A0issues an HTTP GET request by appending "/.well-known/pvd&qu= ot; to the
=C2=A0 =C2=A0trusted name, using the "https" scheme= .

If a Pvd claims to be designated for 10 d= nsZones, and adds that all 10 are also trustedZones, what should the client= do? It sounds like it should send 10 SVCB queries, but if they are not val= idly signed, it should then follow up with 10 GETs (each of which may in tu= rn need A/AAAA queries). Or do you envisage a different algorithm?

References to whitelisting
Section 6.3: <= span style=3D"font-family:monospace">Clients can also choose to only whitel= ist DoH servers that are associated with many names.
Section 8: <= span style=3D"font-family:monospace">Such risk can be mitigated by further = restricting the list of resolvers that are whitelisted for direct use based= on client policy.

It feels odd that whitel= isting is mentioned in this draft but there is no narrative on how it might= work, and what it would need to take into consideration. Do you intend to = cover this in the separate document that updates client behaviour?

Thanks,
Chris


On Thu, 21 May 2020 at 00:04, Tommy Pauly <tpauly= =3D40apple.= com@dmarc.ietf.org> wrote:
Hello ADD,

We=E2=80=99= ve just posted a draft of Adaptive DNS Privacy [1] that=E2=80=99s scoped do= wn to talk about resolver discovery and designation mechanisms, both on loc= al networks and over the wider Internet. This draft is targeted at the focu= s of the ADD group.

https://tools.= ietf.org/html/draft-pauly-add-resolver-discovery-00

= This covers:
- What it means to designate an encrypted resolver
- How to discover resolvers using SVCB/HTTPSSVC records
= - How to validate designation either by validating DNSSEC on these records,= or by performing validation with an HTTPS server
- How to advert= ise a resolver on the local network
- How to discover a =E2=80=9C= companion=E2=80=9D DoH server to a directly known resolver

Thanks to Tommy Jensen for his additional input on some of the loc= al/direct resolver bootstrapping.

We=E2=80=99ll be= publishing other documents that update the behavior for client algorithms = and the use of Oblivious DoH, but we wanted to present this portion individ= ually as the group discusses how best to discover resolvers, etc.

Best,
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000250aba05a6cc2457-- From nobody Fri May 29 17:22:16 2020 Return-Path: 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 EC7613A11E8 for ; Fri, 29 May 2020 17:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 gTVNq3UpL8-J for ; Fri, 29 May 2020 17:22:13 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 07ED43A11E6 for ; Fri, 29 May 2020 17:22:12 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id z13so2525457vsn.10 for ; Fri, 29 May 2020 17:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=goKd7KmCP/J1o4t+LNhW2efhgbRYjufs5ebJC5aibP4=; b=gSfMmjev96pkzTgtBc5pD/hV2beIncUxT4/V7NGJk5EqCKPVZasJvD7VKagiW7Vn0X ofHTstvjlvXsbkT1np+Wu6iXkjiJXlt2gWmxw6USO9FfeU97qUoEhMydG42sH6m0509F rDy3om02MOJ/jVZQy0bXGyNsfoFpiGAT0XDaUu3xNaC9v99GyJj7CNTnXDlvoWmFh8hM FNaQlhF72HoQ5WB0/+ltpqH0H0ddDrqTJWuoRgBNkIoaceo/Pd3uMcByqdbvP4InWT9J EocvN7A9Yj1pJDitGS6Z9xabnhJF+lUUjg4IYQnKB9aVQPaTKaeKlcp17SOmFkE8RpBo lrdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=goKd7KmCP/J1o4t+LNhW2efhgbRYjufs5ebJC5aibP4=; b=lZCmT2QdXo5KY4N3IeU99J1Gd68uTE/bLRSgNSdwR2+XhlE+nhFw3jDmdBjdYlahU/ X/NqfaOpByREb2XwYkC53O9z2VpZ8eAUNNEZN69KmLCsJQEdIUkNQyRjl1g54+jVmg/o nhHzcjOOtYoW0Ley2hXlPB/LOxtI7cdeqEkKe/vCpBHK3cFdibmcfkp2zwFWr7vQLe0z DhjDrmEK+iiwMydYfWaKgLiMBoUZt8ujjIkBFR2fmKqoJRfVAKcVhtCtf5UqkSrHHD0p A6JMyEdJDSE0VKkP2ylWu2EvXL2q5zd/zVEdcwfTjJL3b45q2X2RaymnAzQViEowf32S FGDg== X-Gm-Message-State: AOAM532sPyCTM01aF9QkQGBXxTZbljmuHTwduhf2byYUN39rnlwJTAFX Mxc7xQoZ0Rol29fPsd46mJV6gZsKy6WKjG+WVayTYTGg X-Google-Smtp-Source: ABdhPJywabVEyogmNxS/Hq3naEsnqvRotu+jOmu8cap4wB2uygDHEaWMQjkO2yybkNKzhGFYBHOJ41lO0IgPq5aL2+8= X-Received: by 2002:a67:e88e:: with SMTP id x14mr8122465vsn.180.1590798130673; Fri, 29 May 2020 17:22:10 -0700 (PDT) MIME-Version: 1.0 References: <159078807168.11416.12425165143603046178@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Fri, 29 May 2020 20:21:59 -0400 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000007cfd2005a6d28d12" Archived-At: Subject: [Add] Fwd: Fw: New Version Notification for draft-mglt-add-rdp-02.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 00:22:15 -0000 --0000000000007cfd2005a6d28d12 Content-Type: text/plain; charset="UTF-8" Hi, Please find an update version of the DNS Resolver Discovery Protocol (DRDP) [0]. The document addresses the comments received during the meeting [1]: * enabling multiple third parties to provide a list of resolving domains. * considerations regarding the number of resolving domains. Requirements a discovery protocol is expected to meet have also been re-written. As far as I can see these requirements seems to me aligned with [2]. Expected characteristics of the resolving service have also been added (as SVCParamKey). Of course any feed back is appreciated. Yours, Daniel [0] https://tools.ietf.org/html/draft-mglt-add-rdp-02 [1] https://mailarchive.ietf.org/arch/msg/add/4aUYir095wIcw_5Tclk8uxMH3to/ [2] https://mailarchive.ietf.org/arch/msg/add/6bZfYO5PcTv1F00vARNuHz_NMzE/ ---------- Forwarded message --------- From: Daniel Migault Date: Fri, May 29, 2020 at 6:49 PM Subject: Fw: New Version Notification for draft-mglt-add-rdp-02.txt To: mglt.ietf@gmail.com ________________________________________ From: internet-drafts@ietf.org Sent: Friday, May 29, 2020 5:34 PM To: Daniel Migault Subject: New Version Notification for draft-mglt-add-rdp-02.txt A new version of I-D, draft-mglt-add-rdp-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-add-rdp Revision: 02 Title: DNS Resolver Discovery Protocol (DRDP) Document date: 2020-05-29 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-mglt-add-rdp-02.txt Status: https://datatracker.ietf.org/doc/draft-mglt-add-rdp/ Htmlized: https://tools.ietf.org/html/draft-mglt-add-rdp-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-add-rdp Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-add-rdp-02 Abstract: This document describes the DNS Resolver Discovery Protocol (DRDP) that enables a DNS client to discover various available local and global resolving service. The discovery is primarily initiated by a DNS client, but a resolving service may also inform the DNS client other resolving services are available and eventually preferred. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Ericsson --0000000000007cfd2005a6d28d12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find an update v= ersion of the=C2=A0DNS Resolver Discovery Protocol (DRDP) [0].=C2=A0
The document addresses the comments received during the meetin= g [1]:
* enabling multiple third parties to provide a list of resolving= domains.
* considerations regarding the number of resolving domain= s.

Requirements a discovery protocol is expected t= o meet have also been re-written. As far as I can see these requirements se= ems to me aligned with [2].=C2=A0
Expected characteristics of the= resolving service have also been added (as SVCParamKey).=C2=A0
<= /div>

Of course any feed back=C2=A0is appreciated.=C2=A0=

Yours,=C2=A0
Daniel=C2=A0=C2=A0
[1]= =C2=A0https://mailarchive.ietf.org/arch/msg/add/4aUYir095wIcw_5Tclk= 8uxMH3to/

---------- Forwarded messa= ge ---------
From: Danie= l Migault <daniel.migault@ericsson.com>
Date: Fri, May = 29, 2020 at 6:49 PM
Subject: Fw: New Version Notification for draft-mglt= -add-rdp-02.txt
To: mglt.ietf@gma= il.com <mglt.ietf@gmail.com>





________________________________________
From: interne= t-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Friday, May 29, 2020 5:34 PM
To: Daniel Migault
Subject: New Version Notification for draft-mglt-add-rdp-02.txt

A new version of I-D, draft-mglt-add-rdp-02.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-mgl= t-add-rdp
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 02
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DNS Resolver D= iscovery Protocol (DRDP)
Document date:=C2=A0 2020-05-29
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Sub= mission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-mglt-add-rdp-02.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://dat= atracker.ietf.org/doc/draft-mglt-add-rdp/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/h= tml/draft-mglt-add-rdp-02
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/draft-mglt-add-rdp
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-add-rdp-02

Abstract:
=C2=A0=C2=A0 This document describes the DNS Resolver Discovery Protocol (D= RDP)
=C2=A0=C2=A0 that enables a DNS client to discover various available local = and
=C2=A0=C2=A0 global resolving service.=C2=A0 The discovery is primarily ini= tiated by a
=C2=A0=C2=A0 DNS client, but a resolving service may also inform the DNS cl= ient
=C2=A0=C2=A0 other resolving services are available and eventually preferre= d.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Dani= el Migault
Ericsson
=
--0000000000007cfd2005a6d28d12--