Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?
"Hollenbeck, Scott" <email@example.com> Wed, 07 July 2021 16:12 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CB33A1D48 for <firstname.lastname@example.org>; Wed, 7 Jul 2021 09:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgW_TT7TBvUr for <email@example.com>; Wed, 7 Jul 2021 09:12:52 -0700 (PDT)
Received: from mail4.verisign.com (mail4.verisign.com [188.8.131.52]) (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 <firstname.lastname@example.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" <email@example.com>
To: "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>
CC: "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?
Date: Wed, 7 Jul 2021 16:12:37 +0000
References: <firstname.lastname@example.org> <email@example.com> <LO2P265MB0399126395D4909C0CD29D29C2419@LO2P265MB0399.GBRP265.PROD.OUTLOOK.COM> <CAHXf=0pB0W7gbTWS5fjyppE0YCONti-vBtESWO_uHBfJk3SRBg@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2021 16:12:57 -0000
> -----Original Message----- > From: dns-privacy <firstname.lastname@example.org> On Behalf Of Alexander > Mayrhofer > Sent: Wednesday, July 7, 2021 8:36 AM > To: Andrew Campling <email@example.com> > Cc: Brian Haberman <firstname.lastname@example.org>et>; email@example.com > 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
- [dns-privacy] How do we want to use draft-ietf-dp… Brian Haberman
- Re: [dns-privacy] How do we want to use draft-iet… Hollenbeck, Scott
- Re: [dns-privacy] [Ext] How do we want to use dra… Paul Hoffman
- Re: [dns-privacy] [Ext] How do we want to use dra… Peter van Dijk
- Re: [dns-privacy] How do we want to use draft-iet… Brian Haberman
- Re: [dns-privacy] How do we want to use draft-iet… Eric Rescorla
- Re: [dns-privacy] How do we want to use draft-iet… Andrew Campling
- Re: [dns-privacy] How do we want to use draft-iet… Alexander Mayrhofer
- Re: [dns-privacy] How do we want to use draft-iet… Hollenbeck, Scott