Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 06 May 2021 14:19 UTC

Return-Path: <superuser@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 1B08F3A23D4; Thu, 6 May 2021 07:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnIVdCdi5p-o; Thu, 6 May 2021 07:19:36 -0700 (PDT)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392963A23CF; Thu, 6 May 2021 07:19:36 -0700 (PDT)
Received: by mail-ua1-x930.google.com with SMTP id 33so1756631uaa.7; Thu, 06 May 2021 07:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lGLMubMDMq71MjBlSIwI94dPjfnXR8zDl0JbpFglY20=; b=uhuP8DIxGnrkBAupRZ9Ccf63KzQ/ELolMxOdJhAmb8bHshAgPjXDEZyBA7gh1dsnw4 yjB3BBGgfBhp4GjEWm2SsMdXo6xOZ5GmyJCkkmwWtzWk2ZyRvqo2fz14tpBjxkiJ4lq1 b7p4KmygiltXuoYPtaQZu2HyrLHjBiTtkT1p3iCIo1fZ6nXHZOOV5xLbsDJJmrYvCX+p +BNXNOqRhQlL3hXJV5D6lm+pR49DV4yk6jGpqoQAvvm9WPaFEhlrOBxRHb5iuHqflS4g nGo+6W5k6LbW8HbWNV9XFJHn7Ev8/ZRTy8lHJu+B1JqoSCmVXXgWMkoMZYtGFoWYbao4 nnVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lGLMubMDMq71MjBlSIwI94dPjfnXR8zDl0JbpFglY20=; b=RzFZwMvptIe+Y3sPt5BD3DMHkItM1pd/2O+0pje2tOtmJwDlKeWaxOW0A0ZRhplm5D LgoCGApSbirIQM5LTRXBRe7VutdzFqmlzdzi+EloZqezbtm0PUJalRHe5sLPROT9nBw6 sdW/TB0PCoBheeuOe+kicOgL6n7w7oqEKq+sFgC8P3rPuWTI66E3PTCEPsmK5SmQwVa/ Ln22Mb0qStieDIpjVPfcOVi3tWx43hZ/DeHjKDln65FsPB+WOIuqVKmMqpHJWr8x3H/E nLXGtXB0yhw4cLMtxcl2Zcmk/iJw1VllT7jfzGm+suSQORn6rjaIfWGv/odE/RUnMm// 2bwg==
X-Gm-Message-State: AOAM531VmK2jMlTkNjrTvQxK/Z/jmJYUfRVwOix26Qr52KBQhe5KfQwq 0CR7Nf2HmKlmzFzN2O44m8NDR2hfiI6DIuJpzS8=
X-Google-Smtp-Source: ABdhPJwZoNAVOJJKxnhFMlak9IibOiLidGETJCAb/+CKwvdFxauzGRz0S0jrf74OAdMjxys4SrOT85N1KqINHg736jQ=
X-Received: by 2002:ab0:7003:: with SMTP id k3mr3984133ual.67.1620310774250; Thu, 06 May 2021 07:19:34 -0700 (PDT)
MIME-Version: 1.0
References: <162028190664.14000.16746761589914077982@ietfa.amsl.com> <23EF5929-AC98-44FE-B306-FE16B3852F2A@sinodun.com>
In-Reply-To: <23EF5929-AC98-44FE-B306-FE16B3852F2A@sinodun.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 06 May 2021 07:19:22 -0700
Message-ID: <CAL0qLwZ6Nrsn4hkD_dwxLjLW6WqwbKUWu8JD+=2gmsSMy6Zfrw@mail.gmail.com>
To: Sara Dickinson <sara@sinodun.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000001ffe4405c1aa00b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/L3zN9xYu4oOISMGKpzdwB32kyzk>
Subject: Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 06 May 2021 14:19:41 -0000

On Thu, May 6, 2021 at 4:53 AM Sara Dickinson <sara@sinodun.com> wrote:

> > Section 7:
> >
> > * "Implementations SHOULD use [RFC7828] [...] to manage persistent
> > connections." -- since this is a SHOULD, can you suggest why an
> implementer
> > might opt not to do this?  Section 7.3.1 does a great job of handling the
> > SHOULD it presents, for example.
>
> Implementations typically include an option to use fixed timeouts on
> either side of a connection for simplicity which can work just fine for
> e.g., low transfer rates - I could add text to that effect?
>

Yes, something that rounds out this SHOULD story would be great.

> Sections 7.3.2 and 7.3.3:
> >
> > * Same issue as above with the SHOULDs here.
>
> Short answer, backwards compatibility.
>
> For 7.3.2 there was a discussion in the working group about the
> significant code complexity involved for several implementations to meet
> all 3 requirements (particularly the second two points).  Since the
> performance improvements gained from these features is desirable, but not a
> critical for XFR, the discussion resulted in the SHOULD. Again, could add
> text on that if needed?
>

Adding something like that would be helpful, yes.

For 7.3.3, there is no previous specification for this behaviour and
> nameservers may behave differently today, hence the SHOULD here.
>

Same.

> Section 7.4:
> >
> > * "Therefore, it is RECOMMENDED that [...] there SHOULD be no more than
> [...]."
> > -- I don't know how to reconcile this RECOMMENDED-SHOULD combination in
> the
> > same sentence.  I suggest that the first clause can be dropped with no
> loss of
> > meaning.
>
> Double checking this I remembered that for consistency the text is
> actually lifted and tweaked from RFC7766 which it is updating which said:
> “It is RECOMMENDED that for any given
>    client/server interaction there SHOULD be no more than one connection
>    for regular queries, one for zone transfers, and one for each
>    protocol that is being used on top of TCP (for example, if the
>    resolver was using TLS). "
>
> So we could update it if you feel very strongly?
>

Alas, no.  If you're copying this from something that already has
consensus, it's probably best to leave it.  Thanks for checking.

-MSK