Re: [dns-privacy] [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12

Paul Hoffman <paul.hoffman@icann.org> Thu, 07 September 2023 16:18 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 ADB2DC14CE5F; Thu, 7 Sep 2023 09:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 R--BYXyMEryq; Thu, 7 Sep 2023 09:18:27 -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 7179EC14CF0D; Thu, 7 Sep 2023 09:18:27 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa4.dc.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 387GIOJ6014711 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Sep 2023 16:18:25 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.37; Thu, 7 Sep 2023 09:18:23 -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; Thu, 7 Sep 2023 09:18:23 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Bron Gondwana <brong@fastmailteam.com>
CC: "art@ietf.org" <art@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "draft-ietf-dprive-unilateral-probing.all@ietf.org" <draft-ietf-dprive-unilateral-probing.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12
Thread-Index: AQHZ4ZXycu6vZN3bUk22l4v9zPU3ErAQAAWA
Date: Thu, 07 Sep 2023 16:18:23 +0000
Message-ID: <EC3FE6BF-3296-404F-A888-F2D3D0573FE4@icann.org>
References: <169409620800.15857.16759296263081674061@ietfa.amsl.com>
In-Reply-To: <169409620800.15857.16759296263081674061@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: <6A81432002E3B24D97C7426CEAB4A834@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.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-07_08,2023-09-05_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Yj8sShz1W2LvH6FSauxPUJIrtE8>
Subject: Re: [dns-privacy] [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12
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: Thu, 07 Sep 2023 16:18:29 -0000

Thanks for the review!

On Sep 7, 2023, at 7:16 AM, Bron Gondwana via Datatracker <noreply@ietf.org> wrote:

> My only concern is that it does fall back very easily to cleartext, for a long
> damping period.  As a protocol implementer myself, I would generally expect to
> retry something one or two more times over the course of a few minutes before
> giving up entirely for 24h, since the server at the other end may have just
> been restarting and either dropped an existing connection or rejected a SYN
> packet, but be ready a moment later.  I'd be happy with a limit of something
> like 5 tries over 2 minutes (one every 30 seconds) before giving up.

In Section 4.3, the "damping" parameter has a "suggested default" of 1 day. That's a suggestion, not at all a requirement. It was established based on the idea that almost every domain name has multiple nameservers, and that it is likely that if one server has a failure such as a timeout, the resolver will try the other nameservers (which may or may not be encrypting).

Are you proposing a shorter value for "damping", or a note saying "1 day is just the suggested value, you might choose a shorter one if you want"? Or something else?

--Paul Hoffman