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

Bron Gondwana <brong@fastmailteam.com> Fri, 08 September 2023 01:58 UTC

Return-Path: <brong@fastmailteam.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 4BBDBC151710; Thu, 7 Sep 2023 18:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="fggLE6Zr"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="jbB4mb95"
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 BjXuB85ZE04F; Thu, 7 Sep 2023 18:58:53 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B9B91C15171B; Thu, 7 Sep 2023 18:58:52 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0BF435C0218; Thu, 7 Sep 2023 21:58:51 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Thu, 07 Sep 2023 21:58:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1694138331; x=1694224731; bh=fa/3j7ryxYhmxJpUP9OZ7EkYlX5hNS8l0uF kq1NJzak=; b=fggLE6ZrRbUprO5s9ABPZRANzLgRBtv1zjIx0NmtyrLzFxUoOdX +c9x/wxwRgdepoLC9GhbcifOH6Q40j3WU3zoZYcRpnHfY2XDScd5b8gJCOkvqEx1 4wFD9mQLYRtnPnyj1XwXXeqEYn9O9K09MLwmQE3WsTWKFw7DuLZpVyQwhxN3rhE9 ighr6mfd/dG2tnvgV5X9xbd/5qfj1zUt62Z2chYqyqhZibFo+nlQ60jb9lA4kMT0 frICObpnNRfxiqXfEROiqifS6Ej/vPqFCk9OifYewn0FzmJV1U0jrY4vY3RJpiYI 1/iLlFArko62DGZvNmEZn0ci2wgdi7SC/Xw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1694138331; x=1694224731; bh=fa/3j7ryxYhmx JpUP9OZ7EkYlX5hNS8l0uFkq1NJzak=; b=jbB4mb953tBUUYV+vQn9yFS68C2Y4 PDbay2aUKfQr6O3f4mnFDJD5QOyZbkcxOD5wpVpsUMCCCfCWkgjqpkcBbf4dV9rk URmlV+n7D71j1ChX9g4Gtp2zdGTGVEYHg57ffUq2A7kSzqMRRg6ET4le3TTBJw1z IWO1DM4YLZ+dE+8EeUooVAMsz/y5oUKvxy8alEMJ3j0zlfIK/GaCmlR78SfOo+JH wYcjcdO+SFosSDLtNqnQe9BhYWbZM15+/4hhz9XqSIkSXkk80UP/V9qB7D9cnrLm PqRLj+7at+57+cnSC0e8bPRHuCc56tBm4DdQ/Oc2tHBup4JxhVZb49Gtw==
X-ME-Sender: <xms:2n_6ZFwY0bBGp6_pfT8b1rt8a0eTZpTY3DNFsb2Fm_9Ojrvf195Xrw> <xme:2n_6ZFQjsKnZKxm-YBg-gi0xvdv5Nc9t2yTxqifjp-igUFYulu5Stvb2lR9_3g1b7 5khiKDOsD8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudehiedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfuehr ohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeefvdejgeefhfeftdfggfejvdehieeghfefudevhfeg tddugfeufeelhfelhfeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:2n_6ZPXajOCaUpttEkVJXYHK_TnwbshywKXTmNe4QuE5qOHURnZwOw> <xmx:2n_6ZHjEcL1fX5yubLqlqrIHo6uSzMWH1d2BA8-cuppgydCKZ04tFg> <xmx:2n_6ZHA7a2ThPxie_N6iX4xdw-zTdl8Rrb9tTE822d_z4OZ8ChxPlw> <xmx:23_6ZKNGuG_h5s6TLyzZNGbBQT-w9IyTICgvq5ciXiXw8UMKF8x00A>
Feedback-ID: i2d7042ce:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8CD072D4008F; Thu, 7 Sep 2023 21:58:50 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-745-g95dd7bea33-fm-20230905.001-g95dd7bea
Mime-Version: 1.0
Message-Id: <932d01e4-1bc1-46b9-bd8b-76241b42461c@app.fastmail.com>
In-Reply-To: <EC3FE6BF-3296-404F-A888-F2D3D0573FE4@icann.org>
References: <169409620800.15857.16759296263081674061@ietfa.amsl.com> <EC3FE6BF-3296-404F-A888-F2D3D0573FE4@icann.org>
Date: Fri, 08 Sep 2023 11:58:30 +1000
From: Bron Gondwana <brong@fastmailteam.com>
To: Paul Hoffman <paul.hoffman@icann.org>
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>
Content-Type: multipart/alternative; boundary="c10de63a50af477c97f989a2c0db01a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/g4VPdxrfdCVnPLeR6gpLskB08lA>
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 01:58:58 -0000

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.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com