From nobody Sat Sep 16 09:58:59 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 5E648C151068; Sat, 16 Sep 2023 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 3NjpPBQj1hPp; Sat, 16 Sep 2023 09:58:52 -0700 (PDT) Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.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 10A69C151067; Sat, 16 Sep 2023 09:58:52 -0700 (PDT) Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa4.dc.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 38GGwoSI026379 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Sep 2023 16:58:50 GMT 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 Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.37; Sat, 16 Sep 2023 09:58:48 -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.037; Sat, 16 Sep 2023 09:58:48 -0700 From: Paul Hoffman To: Erik Kline CC: The IESG , "draft-ietf-dprive-unilateral-probing@ietf.org" , "dprive-chairs@ietf.org" , "dns-privacy@ietf.org" , Brian Haberman , Tim Wicinski Thread-Topic: [Ext] Erik Kline's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT) Thread-Index: AQHZ6GOLzQnGbfjpzUK/RD9Ne/2je7AeIrAA Date: Sat, 16 Sep 2023 16:58:48 +0000 Message-ID: <11D26981-8DD7-45AD-8AD4-C9CAF07E4D9B@icann.org> References: <169484421725.20540.17499988491702390674@ietfa.amsl.com> In-Reply-To: <169484421725.20540.17499988491702390674@ietfa.amsl.com> 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: <0318C9D24DD1A7439B3427735CD98634@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-15_20,2023-09-15_01,2023-05-22_02 Archived-At: Subject: Re: [dns-privacy] [Ext] Erik Kline's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT) 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: Sat, 16 Sep 2023 16:58:56 -0000 Thanks for the comments! The fixes below are in a new merge request in the = repo for inclusion in a post-IESG version. Please see my response to your last comment. On Sep 15, 2023, at 11:03 PM, Erik Kline via Datatracker = wrote: > ### S3.1 >=20 > * A 3rd option for a pool operator is to use a load-balancer that forward= s > queries/connections on encrypted transports to only those members of the > pool known (e.g. via monitoring) to support the given encrypted transpor= t. Oooh, good call. Fixed. >=20 > ### S4.2 >=20 > * There is no "port closed" ICMP message. There is a Port Unreachable co= de > under the Destination Unreachable type category. Fixed. >=20 > * The IP addresses given are not "two A records" but rather the values th= at > might appear in an A Resource Resource and AAAA Resource Record. This was noted by an earlier reviewer and is already in the repo. >=20 > ### S4.4 >=20 > * The use of lowercase "must" for the ALPN strings seems a bit odd. >=20 > Should this section say that the ALPN is a "MUST"? It could perhaps be > reworded to say something like "... and if an APLN is included it MUST b= e > ". 25 years later and we're STILL getting THE 2119 capitalizion wrong. Fixed. >=20 > ### S4.6.3 or S8 >=20 > * I think a very important caveat here is when a node running its own > recursive resolver has just joined a network and not yet completed any > captive portal probes. Initiating encrypted transport connections prior > to satisfying the captive portal testing stage could have negative > consequences (especially given the MUST in S4.6.3.4). >=20 > Whether the state of the captive portal check(s) can be known by the > recursive resolver function or not is an implementation-specific matter. >=20 > Yes, this really only applies to recursive resolvers running on mobile > devices, but some devices can actually do this. >=20 Let me first admit my ignorance about captive portals. Wouldn't your concer= n be true for any non-port-53 traffic that any protocol is sending when a c= lient comes up? I'm not sure how to word your concern. I don't think it would be appropriat= e in Section 4.6.3 because it would in essence be saying "First refer to th= is piece of state that we haven't defined". It could be added to Section 8,= but given my lack of expertise in captive portals, I would want the specif= ic wording to come from someone who knows much more. If we can copy the wor= ding from some other RFC that has the same issue, that would be best. --Paul Hoffman