From nobody Thu Sep 7 18:59:00 2023 Return-Path: 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudehiedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfuehr ohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeefvdejgeefhfeftdfggfejvdehieeghfefudevhfeg tddugfeufeelhfelhfeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: 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: References: <169409620800.15857.16759296263081674061@ietfa.amsl.com> Date: Fri, 08 Sep 2023 11:58:30 +1000 From: "Bron Gondwana" To: "Paul Hoffman" Cc: "art@ietf.org" , "dns-privacy@ietf.org" , "draft-ietf-dprive-unilateral-probing.all@ietf.org" , "last-call@ietf.org" Content-Type: multipart/alternative; boundary=c10de63a50af477c97f989a2c0db01a5 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2023 01:58:58 -0000 --c10de63a50af477c97f989a2c0db01a5 Content-Type: text/plain 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 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 --c10de63a50af477c97f989a2c0db01a5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
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 conc= ern is that it does fall back very easily to cleartext, for a long
> damping period.  As a pr= otocol implementer myself, I would generally expect to
> retry something one or two more times ove= r the course of a few minutes before
> giving up entirely for 24h, since the server at the other e= nd may have just
> been re= starting and either dropped an existing connection or rejected a SYN
=
> packet, but be ready a mome= nt later.  I'd be happy with a limit of something
> like 5 tries over 2 minutes (one every 30= seconds) before giving up.
<= br>
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 e= very 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 o= ther nameservers (which may or may not be encrypting).

Yeah, that bit makes sense, so you'll wind up with one of the= m having encrypted connection and the other not - so you'll probably wan= t 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 encryp= ted connection and it has a fault, my reading was that you don't retry a= t all to form an encrypted connection, even when talking to somewhere th= at has previously succeeded.  I agree you don't want to try more th= an 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 de= finitely worth retrying faster than a full day later.

Bro= n.

--
&n= bsp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

=

--c10de63a50af477c97f989a2c0db01a5--