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

Paul Hoffman <paul.hoffman@icann.org> Fri, 08 September 2023 02:15 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 27A05C151981; Thu, 7 Sep 2023 19:15:07 -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 cB8z-ctizOeY; Thu, 7 Sep 2023 19:15:06 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.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 78130C151710; Thu, 7 Sep 2023 19:15:06 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa2.lax.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 3882F3Ck002751 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Sep 2023 02:15:03 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; Thu, 7 Sep 2023 19:15:02 -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 19:15:02 -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: [art] [Ext] Artart last call review of draft-ietf-dprive-unilateral-probing-12
Thread-Index: AQHZ4ZXycu6vZN3bUk22l4v9zPU3ErAQAAWAgACiFQCAAASfAA==
Date: Fri, 08 Sep 2023 02:15:02 +0000
Message-ID: <F7A25965-3570-4516-9D1B-74D0EA93DC4F@icann.org>
References: <169409620800.15857.16759296263081674061@ietfa.amsl.com> <EC3FE6BF-3296-404F-A888-F2D3D0573FE4@icann.org> <932d01e4-1bc1-46b9-bd8b-76241b42461c@app.fastmail.com>
In-Reply-To: <932d01e4-1bc1-46b9-bd8b-76241b42461c@app.fastmail.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: <E2E65A8CAE685B47B068B7E8DEFF794F@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_15,2023-09-05_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/51l7WT5nkz4ZyZeGuiAcNecXb9I>
Subject: Re: [dns-privacy] [art] [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: Fri, 08 Sep 2023 02:15:07 -0000

On Sep 7, 2023, at 6:58 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
> 
> On Fri, Sep 8, 2023, at 02:18, Paul Hoffman wrote:
>> 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).
> 
> Yeah, that bit makes sense, so you'll wind up with one of them having encrypted connection and the other not - so you'll probably want to default to sending further requests to that once since you have it tagged as available for encryption.
> 
>> 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?
> 
> I'm suggesting a backoff algorithm which isn't "single failure gives you N hours of no retry" - particularly, if you have an existing encrypted connection and it has a fault, my reading was that you don't retry at all to form an encrypted connection, even when talking to somewhere that has previously succeeded.  I agree you don't want to try more than once per day against a server that's never supported encryption, but if you have had consistent success encrypting to a server, then a single failure, you don't want to be treating that one the same!  It's definitely worth retrying faster than a full day later.

This sounds like you want a smaller value than 1 day for `damping` then. Because those parameters are only suggested defaults, a resolver operator like you could simply change the 1 day to maybe 1 hour, with the risk of slowing down resolution to that one nameserver.

--Paul Hoffman