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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 07 July 2021 16:12 UTC

Return-Path: <shollenbeck@verisign.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 38CB33A1D48 for <dns-privacy@ietfa.amsl.com>; Wed, 7 Jul 2021 09:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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, RCVD_IN_DNSWL_MED=-2.3, 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=verisign.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 zgW_TT7TBvUr for <dns-privacy@ietfa.amsl.com>; Wed, 7 Jul 2021 09:12:52 -0700 (PDT)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70873A1D43 for <dns-privacy@ietf.org>; Wed, 7 Jul 2021 09:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2748; q=dns/txt; s=VRSN; t=1625674361; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=KHN1EDhDExxWrIIv5icxq+hivEJmjxfxp0sdPgkg1Nk=; b=JcW4Q6RcvSYYzju+mG+ZmoM5RGOJDHuEAt5U9Nccl6Mt0dK7nKQzKxsL ww7keIrsGRlQQN7KRGUwy0+js8pg6/+VMYgCYB+ehnbJ9dcNar//CQT/F +z4OEScpSj234W/hMJV2kg0pcCjtstNsMIBD9CbCKLNqCO2ZCsb3k1bYe iDshv9gaCXLYleK0hrsKSb3Uj7GngCQ6Rm8uXIQpKpfuKzPCc5UK3O4+w DgE+aeLLmErEveO7+fC3RWGOo5kYuMj+QVRc745cX20+pOS82PRAc9Fok kMn417r1MeamWTSsGH5ncHxdnP/BWiYHVRQGzGlLAjLWDawAQqz1B1GrS A==;
IronPort-SDR: rL+kblB6C4sHwLgsqElK50IP/BEsUzhA/iFK7bThyZTudrBpR9K2A3mBrLcWVUwPU/UCKEMhdk HF8060KU2gr5ExwLYNY9QSnHZTl0F1VLoCrdjetBMVyKo6CKb+ipXV8ev8cNMTC41jprfn1pdQ mUadjv3xR4kP973aNDc/4cBCpfOQ2axhh8eW16OdBWmAKXhM0g+IUNo3aatEvImjq4/1s0Jq7b jfsSWYJZU2+2bWhNcyHB5CZrUWGWlHfJwZEijgb7Tf6ay07KqaNK4Eod0Q+y5J9qzB3XeBbncA SEc=
IronPort-HdrOrdr: A9a23:bBRnyKjy84LZMnPOyWrKukrNUnBQXgcji2hC6mlwRA09TyX+rb HKoB17726XtN9/YhEdcLy7VpVoIkmyyXcd2+B4AV7IZniEhILHFuBfxLqn7THmFzb36+JRkY xxGpITNPTASXx3l9zz7gX9MdoxqePszImYwcPT1W1kQw0vUbxn9AsRMGumO1d7XxZLHqA0E5 eg5s5KzgDKRUgq
X-IronPort-AV: E=Sophos;i="5.84,220,1620705600"; d="scan'208";a="8510557"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 7 Jul 2021 12:12:37 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2242.010; Wed, 7 Jul 2021 12:12:37 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "alex.mayrhofer.ietf@gmail.com" <alex.mayrhofer.ietf@gmail.com>, "andrew.campling@419.consulting" <andrew.campling@419.consulting>
CC: "brian@innovationslab.net" <brian@innovationslab.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?
Thread-Index: AQHXcyzLuGq59L8B906GdUeBg+dpeas3rFdg
Date: Wed, 7 Jul 2021 16:12:37 +0000
Message-ID: <1cee51dc2bad485bb4ad035ec1396395@verisign.com>
References: <121ae494-d7f0-37da-cf53-44f75df2fa75@innovationslab.net> <51ecd372-c178-14ff-5168-81e2e87350e9@innovationslab.net> <LO2P265MB0399126395D4909C0CD29D29C2419@LO2P265MB0399.GBRP265.PROD.OUTLOOK.COM> <CAHXf=0pB0W7gbTWS5fjyppE0YCONti-vBtESWO_uHBfJk3SRBg@mail.gmail.com>
In-Reply-To: <CAHXf=0pB0W7gbTWS5fjyppE0YCONti-vBtESWO_uHBfJk3SRBg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/LjDiRX_WD7KDW1zWpXbPPOsW8Fo>
Subject: Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?
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: Wed, 07 Jul 2021 16:12:57 -0000

> -----Original Message-----
> From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of Alexander
> Mayrhofer
> Sent: Wednesday, July 7, 2021 8:36 AM
> To: Andrew Campling <andrew.campling@419.consulting>
> Cc: Brian Haberman <brian@innovationslab.net>et>; dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] How do we want to use draft-ietf-
> dprive-phase2-requirements?
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 
> 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?

[SAH] I'd certainly like to see both design _and operational_ considerations captured somewhere, and it makes sense to do it in one place.

There's another expired draft that attempted to capture operational considerations:

https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/

It would be worth exploring it, too, if we see value in capturing this information.

Scott