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

Rob Sayre <sayrer@gmail.com> Wed, 13 September 2023 03:01 UTC

Return-Path: <sayrer@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 9923DC15DD6A; Tue, 12 Sep 2023 20:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, HTML_MESSAGE=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 q9YNfQVNEjkY; Tue, 12 Sep 2023 20:01:00 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 0B118C14CEFA; Tue, 12 Sep 2023 20:01:00 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-500cfb168c6so10356937e87.2; Tue, 12 Sep 2023 20:00:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694574057; x=1695178857; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ofMsbXTap12kso1vBdaE1ql5ws+8AmBt8Fy5jiRbLLA=; b=dyfMZKbOkI39zQKjF7bZcQE3EyKdDhJvzWGFvkk1bkRUO44V8uy1YTCJA9FUG/nzM0 PLSzRxf6z2Yb/lC2yRT0PIUF3gvZt/RaJKThj10moXM+a5hNfYp8JaxuCRDRHPLTv5jW r6ylw2oThm+Al8lYe26a+KaSe2MPoCc00mar5Hyx6rHC3HliMlJeBMowXspgElmdsu7L VfRrUNgK4Ko2bs0YGBNn+qIdAc2JqTofhDNuy1oqFqs+YKDwyFVBbQI7cvfDDF05Rhnc luxk9AYmwo9HMnhgV4FZ4tyZS0a2VFZugd5kLPbVzB/eee/XYoGx257JEQINBlnq1xvk 8oCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694574057; x=1695178857; h=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=ofMsbXTap12kso1vBdaE1ql5ws+8AmBt8Fy5jiRbLLA=; b=L8JjKP9kevnyRAWJHOIpQDoMpXXU9lTmi39kGQNBldSwYeFPnrsUk4xNm/YCPAxGq4 HE0rBNynSMK8L9jxJt87XYskwml2MU8o3BXPKPFLzj/RqU4AJpX8hS8tYjsvStrEyK7+ p+VFYRO9DUeWk6sQtuGqEhfl7+0hZ9RtgMhBYKuuas5mN6FZHM5c/k4FTJGSujlZ/0eA nIEzUSvER11WXHHm48rDUnkCwBWu2jW40xbU0SJY05cshxr0hMxVCSSsNQG2WXCBu8ZM 9FYMahCFys1pesUufGJ66tz61+cDfuPnROjw7XG1JfgStEmwWR7wMrM/9SBYBa84ra7J mTpg==
X-Gm-Message-State: AOJu0YzZsPX0m7aPKzcsyGLcqxNPkGaA43OkEN0/3KsR8rsori1SZF/N jt1WBcoj2HC9qmfZjOkmDMpey0DF6rQ2z0HPQDzHvFjgejdARA==
X-Google-Smtp-Source: AGHT+IHmg2v2DOh2c+cLL2/XjDbsglJh8i2qw+0kByhUmd8/EdABWhR04rc89rfv7lBYAlk/1DFlKhv3KOnIOXLLzLI=
X-Received: by 2002:a2e:b0d7:0:b0:2bd:21c1:3e4 with SMTP id g23-20020a2eb0d7000000b002bd21c103e4mr1258961ljl.34.1694574057232; Tue, 12 Sep 2023 20:00:57 -0700 (PDT)
MIME-Version: 1.0
References: <169409620800.15857.16759296263081674061@ietfa.amsl.com> <EC3FE6BF-3296-404F-A888-F2D3D0573FE4@icann.org> <932d01e4-1bc1-46b9-bd8b-76241b42461c@app.fastmail.com> <F7A25965-3570-4516-9D1B-74D0EA93DC4F@icann.org> <CAChr6Sydrhs9i+WnzA9gBOuvGCE7_5ndNEJEmUTZLKxU6e9YrQ@mail.gmail.com> <87a5tqzzoi.fsf@fifthhorseman.net>
In-Reply-To: <87a5tqzzoi.fsf@fifthhorseman.net>
From: Rob Sayre <sayrer@gmail.com>
Date: Tue, 12 Sep 2023 20:00:45 -0700
Message-ID: <CAChr6SxwOcdE57RYDPHPwDLwa__HoohD6gVcykaC=qh3qNKbUA@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Paul Hoffman <paul.hoffman@icann.org>, Bron Gondwana <brong@fastmailteam.com>, "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="000000000000ba1e90060534c46c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Cen3TKUrhx_518mTu-h6mq1yNEA>
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: Wed, 13 Sep 2023 03:01:00 -0000

On Tue, Sep 12, 2023 at 5:26 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

>
> Thanks for all this discussion.  The main purpose of having any sort of
> damping in the draft is to encourage operators of authoritative servers
> that they will not find themselves in trouble even if they enable
> encrypted transport briefly for experimentation or evaluation, and then
> turn it off again.
>
> There are two kinds of trouble that such an authoritative server could
> find itself in:
>
>  a) It could be flooded with queries on a transport that it no longer
>     supports.
>
>  b) Queries from recursive resolvers could fail or be substantially
>     delayed when the encrypted transport is disabled.
>
> The `damping` parameter primarily influences (a), which i'd argue is
> likely the less-important of the two, operationally, since it doesn't
> cost the authoritative operator that much to send a "port closed" ICMP
> response.  ((b) is influenced more by the `timeout` parameter.)
>

[...]

>From my perspective, the simple approach described in the draft is a
> good opportunistic baseline -- minimally complex, works fine
> (opportunistically) with a functioning server in the absence of an
> active attacker, and fails gracefully in the face of errors on the
> server side.
>

I still think this is wrong, because connection establishment is the
expensive thing here. But I don't object strongly.

Let's say the server network hardware gets unplugged for 30 seconds. Does
everyone then try to re-establish an encrypted connection 24 hours later?
In this situation, the operator cannot send a "send a 'port closed' ICMP
response", because the network is broken. The reason to insert at least a
little bit of variability in the retry requests is to help bring up a
server after something close to the server breaks.

The other way to deal with this problem is to arbitrarily reject
connections at the server as things come back up, but the draft then
recommends another 24 hours.

thanks,
Rob


thanks,
Rob