Re: [dns-privacy] [Ext] Erik Kline's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)
Erik Kline <ek.ietf@gmail.com> Sun, 17 September 2023 04:06 UTC
Return-Path: <ek.ietf@gmail.com>
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 9CB63C14CF15; Sat, 16 Sep 2023 21:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Us3U-Zq7nnB2; Sat, 16 Sep 2023 21:06:30 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C5AC14CF0C; Sat, 16 Sep 2023 21:06:30 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3a76d882052so2217330b6e.0; Sat, 16 Sep 2023 21:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694923589; x=1695528389; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yLsUAJ2gk1WECRPrMrmhDg65j2bzOFAE+vf7EqKzMv8=; b=NzCoGM3IJqMZ+J8UXSjJyE082TE+Ilyv62R2e8zk085gbFS9hS+gtsD/bC3GPc2EGg SOXJROACCI9zZCme/5yj5dkO1PceFKQ+SK4h4gLNqfdbZHFfJJ5phPPCbQVHsnWRxrEv o05RetNzz+nUBkDpAKYgq9Wr15CX1aSZrnIhUtP/jlyVj7+8oEjFMI/iP8IS52gjtfpc PZhO1e5TZssGO1tWkoj3sPfCvslxOtzRFqVom62umwX69/opiApYn1NBcpKupkFeI6ev YV55zXmoLR+/JmTDXDi7FasU77A4T3FhFzz6t6YkfJbyxYHGfZZh6zfpwM2bw+cWXsUw 3E7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694923589; x=1695528389; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yLsUAJ2gk1WECRPrMrmhDg65j2bzOFAE+vf7EqKzMv8=; b=IoniSi82xNC1eDhGC0AfTFOFKLyg+O+dfoRkHzLfxKmUxJm2J+cfWSzvvm3AY272y+ xrB57e5OaYbqIGgK+aE6kk8hiRgWenhTBoPeIGeBfAb8tI08xE9WIIOrVp8bZ2VrPQdm t5n2ceXhhnATN4JJNOiwP+sJmiTpZX58THqUIcsu+ftEGJYh1oTrhzenviMIKG62U8tq xcesIY7Vgau7WyMT1lA41bT/MYfFwYQTT2GNvtqvCEWVqjLF/OJEZcY0rFH6E4IETMgo 7SfPpPm2jqOtk2nfCij4z8wgPl0ZwbWwJAnORrkyKrTnroXatQDqAN0DBEwLE2AYQ+7M TpdQ==
X-Gm-Message-State: AOJu0Ywx/mdoSYPugbZFLvqRMmpnCNn4Mm3tL3pa+WfH5fJzsfUQsqsp 6hEd4uWHI9C4n5AvkNVFzU7QLVwaF2xh2RDzjgg=
X-Google-Smtp-Source: AGHT+IEWYYKVt64+ay2NZU7jxcnXa9ultTQYqXQqj6KdAQeMHAV5yIu8YwlznU+ev3qZgImduWV1x9qkZc4d6kdlUYM=
X-Received: by 2002:a05:6808:7ca:b0:3a7:4b9a:43ca with SMTP id f10-20020a05680807ca00b003a74b9a43camr6039427oij.53.1694923589237; Sat, 16 Sep 2023 21:06:29 -0700 (PDT)
MIME-Version: 1.0
References: <169484421725.20540.17499988491702390674@ietfa.amsl.com> <11D26981-8DD7-45AD-8AD4-C9CAF07E4D9B@icann.org>
In-Reply-To: <11D26981-8DD7-45AD-8AD4-C9CAF07E4D9B@icann.org>
From: Erik Kline <ek.ietf@gmail.com>
Date: Sat, 16 Sep 2023 21:06:18 -0700
Message-ID: <CAMGpriU7VFQP-_-QqqAHX_8H2EB_Ug_7WRYU0eXipMLOpCdrmg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/IrtyObL5Gwd4XP5-N88mqopIGt8>
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: Sun, 17 Sep 2023 04:06:30 -0000
> > ### 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. Yeah, I think Section 8 probably makes more sense than any other section, as far as potential comments go. I took a stab a potential paragraph that might be appended to Section 8: As discussed elsewhere, the protocol described in this document provides no defense against active attackers. On networks where a captive portal is operating, some communications may be actively intercepted, e.g. when trying to redirect a user to complete an interaction with a captive portal server. Nodes that perform captive portal detection and Internet connectivity checks are RECOMMENDED to delay recursive resolver encrypted transport probes until after the node's Internet connectivity check policy has been satisfied. (This is what the first iteration of Private DNS on Android did, FWIW.)
- [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