Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Tue, 22 March 2022 16:51 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 50B443A094A; Tue, 22 Mar 2022 09:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 UAfQ9fyLL640; Tue, 22 Mar 2022 09:51:41 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 2F1D43A09D1; Tue, 22 Mar 2022 09:51:41 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id w21so1859064uan.3; Tue, 22 Mar 2022 09:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BkJjt8cPKtYuFmpf6XHKNlU37rdd7Ic6MgkjY0UiCKI=; b=fWQ+gw0wo004FfMLHTfpCWiVf78NMN028665peyOFAwufsPAZ5+pUV7YUCJtx+5zCW nyoVbbCmTOQrkRfdiC5q6A1d8pe2gGKrbU7u+ShyTlyMJXEbT7MvgvKaRl2KhNvV+4YX yUEWRoBLizJ4CWAg4DThXroLXnF1xWdFgFFl2fxYYr9ZG1zauYiT246pRN6z0arQr4C3 lb4SbYmoNKn0BsyqTYe+HvBiGyXNti6Cg+GzWyg2lbJGtyQvZ7v9g3jxN+KYixxQLc5b 6WJ6QioNXUXBUil4OVHXXcnRH6Bhm7AfypGv7TVQtk7JOWZtTCHVe4k+LPRFv+JQIu1Q 1Q7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BkJjt8cPKtYuFmpf6XHKNlU37rdd7Ic6MgkjY0UiCKI=; b=wDgY88424qqNXWFIyeqFDok/XlrpNvz+xS+9sYbl6J+D8gBwkj+2TCp/6RcIQKw0o5 ECpGYaihXE1oUe04oz6gUGfaED3xbo8CC+zSc3hSsBykWgddBtRieFSMZLGgms3K5dTc Tanc8Ew9NaJHOqUmmRex1n4PTeRG6OBBrkyzmiYi8nD5IbJEZGdXTiHEWc7cefQ7LgFJ ag5bFBkbBmaaqN6LReBxsSW9If+kWtRecGLXUmpuaSmIOnTZfWJxOKCSvivBVIVPxW/G R5hDhOlaudfl6OdaFPHBnUdkgesw9UGoaDzDpmmZvhg2IFlC8wKgr050aLIw9xjoJuyp OCGg==
X-Gm-Message-State: AOAM532BoDtk4r3WZ+Dts2CUv3yjgnVnSETElNWIyxoxw/vaaI6Id9hY Gtb9JwD3+HiDpsACGh7rlAAsfP6r3O8h60jJCS6auxvYIcw=
X-Google-Smtp-Source: ABdhPJyZAAgjKstbpQP1G1LxcUrz6yExg9Se22/EmuFkgX5Rk8AvbAY8lVGYCWITmIxX4Q/pdlsx+tndDcuCV3E2Q9Y=
X-Received: by 2002:ab0:7784:0:b0:34a:a130:af24 with SMTP id x4-20020ab07784000000b0034aa130af24mr9737544uar.67.1647967899984; Tue, 22 Mar 2022 09:51:39 -0700 (PDT)
MIME-Version: 1.0
References: <164688802361.27357.3045938985642915716@ietfa.amsl.com> <DFAABD83-F3D1-4B2A-AC90-7827B113D0F0@sinodun.com>
In-Reply-To: <DFAABD83-F3D1-4B2A-AC90-7827B113D0F0@sinodun.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tue, 22 Mar 2022 09:51:28 -0700
Message-ID: <CAL0qLwa00dbMZW=9xgcSY5e8Y+VsigOMb5an4zbHM3JMeECmtw@mail.gmail.com>
To: Sara Dickinson <sara@sinodun.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-dnsoquic@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, Brian Haberman <brian@innovationslab.net>
Content-Type: multipart/alternative; boundary="00000000000047a7ae05dad16d05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/jCCYeWodaiYiAPMX71YRIAM19ls>
Subject: Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 22 Mar 2022 16:51:47 -0000

Hi Sara,

On Tue, Mar 22, 2022 at 2:40 AM Sara Dickinson <sara@sinodun.com> wrote:

> > In Section 5.5:
> >
> >   Clients SHOULD consider potential privacy issues associated with
> >   session resumption before deciding to use this mechanism.  [...]
> >
> > I find "SHOULD consider" to be far too vague for this to be meaningful.
> If
> > I've thought about it, have I met my burden here?
>
> There are several things to evaluate here - we’ve updated this text to:
> “Clients SHOULD consider
>  potential privacy issues associated with session resumption before
> deciding to use
>  this mechanism and specifically evaluate the trade-offs presented in the
> various sections of this document. The privacy issues are detailed…"
>
> Does that address your concern or can you suggest text?
>

I'd be fine with either the original or proposed text if you make it a
lowercase "should".

I guess for me this comes down to: Why is this a "SHOULD" and not a
"should"?  What specific normative obligation are you imposing with this
sentence that affects interoperability of the protocol?

If after considering potential privacy issues, it's really the case that
there are specific protocol things I need to do, then I would enumerate
those explicitly and make them SHOULDs.  But a general "You SHOULD think
about this" doesn't feel to me like correct use of BCP 14 keywords.

-MSK