Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?

Alexander Mayrhofer <> Wed, 07 July 2021 12:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF6023A1172 for <>; Wed, 7 Jul 2021 05:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NKSpGrjVq2Qi for <>; Wed, 7 Jul 2021 05:36:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2D463A116C for <>; Wed, 7 Jul 2021 05:36:39 -0700 (PDT)
Received: by with SMTP id n14so3783825lfu.8 for <>; Wed, 07 Jul 2021 05:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jGFHDei9mkG6TuYrc0Ok1yZdk0Oylcydp2MHQCEkspQ=; b=daPnCU48qqsyqRbeyRQNrvLC4d2N228Vc6fqcDoy8JfFI9bLKgdcBtLF1fNVOtNFjx RQ21AwBml8Nj9swe+M4/XaQaCZ7sZHW0ab/oU9R8Bslh4Jx1wDwZjrEmxk2UOAwiAscg gSCfRkkpKRKccp08jkaB2VFUTiXV8M4PDiyDSrr/dwzyXO9BfcFwqxfhRNs2wafSzCF3 6cgfkQ15Hci8H9skD3PcD5ZKGod21IRWqMSTW5lw/SnFI+ebVxK9BeRcSlW0re1Mo8W+ MHmffETzKiGCfmxK2ITMOtPGdpGqc46nDKINl5gYwu4rKzxNWQ1mHlFuYHvCYx1RCu4g hZDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jGFHDei9mkG6TuYrc0Ok1yZdk0Oylcydp2MHQCEkspQ=; b=efrB02wwM/mHEDHo0vY9Wxu/TsjRHTnRThS7h/mfKdLpuP5xIT5gOdXhWqhPpZ0gy/ yEzq9T06DBCfA9Nm/39vuPR+VMUrTlz1pX3g4asqgCKrgZhu8XO8AWtQwRSCMmuP6qOu tPN1uY1nwUz2ot9uAaiabP/jXSmn1UtDjXBWESFZc+0QNfigbjUgtJKRInXcnyB8fgk/ yjp02rhpikIPbutUjNYWZzg+QxB5S8bSnU9Dw5U32dIDHubNe9CwZ8vSQuiaoO67csgN NulvZrgaEa1PVrNfruTCYNyz3sY4LTsqK24s2ep4AycKVfHvCFQ3FAqzEChOrlYj7Ikq ak/g==
X-Gm-Message-State: AOAM530ssVWUPY+nbPYKMK2s6QS/As92RX9R9Abr2FDblccaAy76TUpv L2f6XZQszsvOeU55LCoQwmK7mYBGJVkcfCmAGxE=
X-Google-Smtp-Source: ABdhPJznAI2vymi/uPfZvt3ev4V0M58NsgpL2MirI+flvFvp9AArxCWdRrZuUPdNlcaPJvEwT+htHNHuiO/v3LL5Jmo=
X-Received: by 2002:ac2:548a:: with SMTP id t10mr4587055lfk.247.1625661396570; Wed, 07 Jul 2021 05:36:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <LO2P265MB0399126395D4909C0CD29D29C2419@LO2P265MB0399.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <LO2P265MB0399126395D4909C0CD29D29C2419@LO2P265MB0399.GBRP265.PROD.OUTLOOK.COM>
From: Alexander Mayrhofer <>
Date: Wed, 7 Jul 2021 14:36:25 +0200
Message-ID: <>
To: Andrew Campling <>
Cc: Brian Haberman <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?
X-Mailman-Version: 2.1.29
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: Wed, 07 Jul 2021 12:36:45 -0000

Picking up on this (speaking as an editor of the draft). I don't have
any issues with option #4 (dropping the draft), and it has expired
some time ago anyways. However, if we need a space to document
operational concerns around any specific solution (for example, to
avoid repeating the same concerns for each new solution space
document), then i think the document could provide a useful
contribution to the WG. Also, i do remember that we initially mulled
never progressing the draft to an RFC anyways, so it seems its current
fate pretty much fits that original intent.

If we do want a space to collect "concerns", a document with
"requirements" in its name would be slightly misleading, though -
"design considerations" or similar would probably fit that purpose
much better. We could also use a wiki page somewhere for that, but i
think even an expired draft is a more stable resource, compared to a
WG wiki page.

Some of these "design considerations" i've heard / can think of over
the last years would be:

- Protocol should not require any probing by recursive servers
- Protocol should require as little state as possible
- Recursives would have a much larger set of open "upstream"
connections than a stub resolver (obviously), so footprint of these
sessions is critical
- Auth servers would see a similar amount of open "downstream"
connections, though that end is probably similar to what recursives
see downstream - are there differences?
- Quality / Level of authentication ("better than nothing" principle?)

So, if we go for option #4, would it make sense to collect those (and
similar) considerations somewhere?


On Tue, Apr 27, 2021 at 11:25 PM Andrew Campling
<> wrote:
> On 26 April 2021 20:45, Brian Haberman wrote:
> > Does anyone else have an opinion on this?
> > On 4/19/21 5:13 PM, Brian Haberman wrote:
> >> All,
> >>      As was raised on the thread discussing suggestions for the
> >> requirements draft, there is some question on how the WG wants to use
> >> draft-ietf-dprive-phase2-requirements in progressing our
> >> recursive-to-authoritative privacy work item. The draft currently has
> >> one sub-section that describes requirements (5.1) and another section
> >> that describes optional features (5.2), albeit with 2119 SHOULDs.
> >>
> >>      My question to the WG is how do we want to use this draft? I see
> >> four possible approaches, but I am sure someone will point out others.
> >>
> >> 1. Strictly requirements - these would be MUST-level functions that
> >> the WG determines have to be supported by any solutions draft.
> >>
> >> 2. Strictly design considerations - these would be functional areas
> >> that the WG determines need to be considered, but not necessarily
> >> included, by any solutions draft.
> >>
> >> 3. Requirements & design considerations - This is generally where the
> >> current draft sits IMO.
> >>
> >> 4. Drop the draft and let the solutions flow.
> >>
> >> Let's discuss the focus of the draft and then we can determine what
> >> updates are needed/necessary.
> >>
> >> Regards,
> >> Brian
> >>
> Building on the Root Server Operators Statement on DNS Encryption, I think there would be benefit in gaining input from TLD operators to establish whether they are interested in adopting encryption, as well as any insight into deployment considerations, the relative attractiveness of potential solutions etc.  Developing solutions without sufficient understanding of the requirements and operational concerns of the intended beneficiaries risks wasting a lot of effort pursuing the wrong solutions to the wrong problems.  Capturing this information would seem to fit within a requirements document.
> Andrew
> _______________________________________________
> dns-privacy mailing list