Re: [dns-privacy] [Ext] Erik Kline's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)
Paul Hoffman <paul.hoffman@icann.org> Sat, 16 September 2023 16:58 UTC
Return-Path: <paul.hoffman@icann.org>
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 <paul.hoffman@icann.org>
To: Erik Kline <ek.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-dprive-unilateral-probing@ietf.org" <draft-ietf-dprive-unilateral-probing@ietf.org>, "dprive-chairs@ietf.org" <dprive-chairs@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Brian Haberman <brian@innovationslab.net>, Tim Wicinski <tjw.ietf@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/dns-privacy/1ND4cLwjA8ueT0EcvlECmSgRYbg>
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 <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=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 <noreply@ietf.org> wrote: > ### S3.1 > > * A 3rd option for a pool operator is to use a load-balancer that forwards > queries/connections on encrypted transports to only those members of the > pool known (e.g. via monitoring) to support the given encrypted transport. Oooh, good call. Fixed. > > ### S4.2 > > * There is no "port closed" ICMP message. There is a Port Unreachable code > under the Destination Unreachable type category. Fixed. > > * The IP addresses given are not "two A records" but rather the values that > might appear in an A Resource Resource and AAAA Resource Record. This was noted by an earlier reviewer and is already in the repo. > > ### S4.4 > > * The use of lowercase "must" for the ALPN strings seems a bit odd. > > 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 be > <the_thing>". 25 years later and we're STILL getting THE 2119 capitalizion wrong. Fixed. > > ### S4.6.3 or S8 > > * 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). > > Whether the state of the captive portal check(s) can be known by the > recursive resolver function or not is an implementation-specific matter. > > Yes, this really only applies to recursive resolvers running on mobile > devices, but some devices can actually do this. > Let me first admit my ignorance about captive portals. Wouldn't your concern be true for any non-port-53 traffic that any protocol is sending when a client comes up? I'm not sure how to word your concern. I don't think it would be appropriate in Section 4.6.3 because it would in essence be saying "First refer to this 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 specific wording to come from someone who knows much more. If we can copy the wording from some other RFC that has the same issue, that would be best. --Paul Hoffman
- [dns-privacy] Erik Kline's No Objection on draft-… Erik Kline via Datatracker
- Re: [dns-privacy] [Ext] Erik Kline's No Objection… Paul Hoffman
- Re: [dns-privacy] [Ext] Erik Kline's No Objection… Erik Kline