From nobody Fri Jul 21 11:56:43 2023 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC8C15108C; Fri, 21 Jul 2023 11:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA4ixoZO40OL; Fri, 21 Jul 2023 11:56:40 -0700 (PDT) Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 E315AC14CEFE; Fri, 21 Jul 2023 11:56:39 -0700 (PDT) Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa5.dc.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 36LIucoN030431 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2023 18:56:39 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Fri, 21 Jul 2023 11:56:37 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.1118.030; Fri, 21 Jul 2023 11:56:37 -0700 From: Paul Hoffman To: "Eric Vyncke (evyncke)" CC: "dns-privacy@ietf.org" Thread-Topic: [Ext] [dns-privacy] AD review of draft-ietf-dprive-unilateral-probing-09 Thread-Index: AQHZuKcWOROzZeeAlU+h5/kTGbtASK/FDjGA Date: Fri, 21 Jul 2023 18:56:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: True Content-Type: text/plain; charset="us-ascii" Content-ID: <6D5E7BD265B2FA44BB3E830F94EC9198@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-21_10,2023-07-20_01,2023-05-22_02 Archived-At: Subject: Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09 X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Addition of privacy to the DNS protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2023 18:56:42 -0000 Substantial bits below; others were accepted withtout note. On Jul 17, 2023, at 5:06 AM, Eric Vyncke (evyncke) wrote: > # Shepherd's write-ip >=20 > The shepherd's write-up states "the WG would like to ensure that this lis= t remains in the document once it is published as an RFC" but the appendix = A states "RFC Editor: please remove this section before publication". I.e.,= the shepherd's write-up and the I-D MUST be coherent ;-) Paul Wouters pointed out on the list (2023-07-02) that Appendix A is not in= the format from RFC 7942, and is not at all definitive, and thus can be re= moved. > # Section 1.1 >=20 > I am always uneasy with the use of BCP14 normative language outside of a = standard track or BCP document. I agree with your unease, but it is a long-established tradition in the RFC= Series. If the IESG and IAB and ISE want to create new guidance on that... > # Section 3 >=20 > This was probably discussed over the mailing list, but must DoT & DoQ rep= lies be also identical to Do53 replies ? The current text is a little under= specified. The last paragraph of Section 3 says "An authoritative server implementing = DoT or DoQ MUST authoritatively serve the same zones over all supported tra= nsports." How should we say that differently to be more specfied? > # Section 3.2 >=20 > In ` The simplest deployment would simply provide a self-issued, regularl= y-updated X.509 certificate` is the intent to use short-lived certificates = ? Or more to state "valid certificate" ? The text would benefit from clarit= y. There is no intent for short-lived or long-lived: that's totally up to the = deployment. Also, self-issued certificates are not valid, they are only ver= ifiable. > # Section 3.5 >=20 > Expect some comments during the IESG review if the SHOULDs do not have so= me wording about when the SHOULDs does not apply. To increase the anonymity set for each response, the authoritative server SHOULD use a sensible padding mechanism for all responses it sends when possible (this might be limited by e.g. not receiving an EDNS(0) option in the query). Specifically, a DoT server SHOULD use EDNS(0) padding [RFC7830] if possible, and a DoQ server SHOULD follow the guidance in Section 5.4 of [RFC9250]. How much to pad is out of scope of this document, but a reasonable suggestion can be found in [RFC8467]. The first SHOULD says it does not apply when not receiving an EDNS(0) optio= n. The second points to the logic in Section 5.4 of RFC 9250. What more cou= ld we add? > # Section 4.4 >=20 > Unsure whether the last paragraph has any value... ` a recursive resolver= implementing these strategies SHOULD also accept queries from its clients = over some encrypted transport (current common transports are DoH or DoT).` That was requested by the WG. > # Section 4.6.10 >=20 > Only one prioritization scheme in this section while there were two in se= ction 3.4 Section 3 is about authoritative servers, Section 4 is about resolvers. In = general, no one gets too concerned about resource exhaustion in resolvers. = After the deployment experiemt, maybe that will change. We will turn in the -10 during IETF117. --Paul Hoffman