IETF Logo Mail Archive

Re: [dns-privacy] [Ext] WG strategy on opportunistic vs authenticated moving forward

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 13 July 2021 16:32 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 181EC3A0763 for <dns-privacy@ietfa.amsl.com>; Tue, 13 Jul 2021 09:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 UNxRRbKMsDww for <dns-privacy@ietfa.amsl.com>; Tue, 13 Jul 2021 09:32:26 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.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 74B4F3A0691 for <dns-privacy@ietf.org>; Tue, 13 Jul 2021 09:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1452; q=dns/txt; s=VRSN; t=1626193946; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mMAxCPZubBF7N/RpinjQGVKkcwWVGYhs9pitp9wG6iU=; b=ftUkdqkLKNXGCz/Mmxg9ao2hJnv3TGyiDYbjQlJGxXEi+bFlGIEJSpUX CqxYuXIEZoDVqCSkiV8ARApxMBoAf8jDxjsMkNjNwnU3Zq623kCj9fSkw 21EbbAVSaBYu1pkLP3o/+GvrShkJkTkNUePpUR7kalLuGCylAIYVq0KQK OdurPX4sCEJanSeOKER1JDC3+X26bc4hDLRlz0HtXT1NYSVjVi+f6d9g6 GOVn42UA1hrFXwh921egFpLrHcOVgI3VrKpbcAkvGfRkWxH+aueK4EDPG zYZjGzbsGkcvo9weQ+HMxqzVbyUn6E3PVzRM9Jp1INHO5yYZ7uw1CsB8S A==;
IronPort-SDR: D0m5hPABXl0uarogQAyznBTWuVsQIcAfAnqHJ3sMwDzX1JoRPnJAnwehtSKL2Dy/BghQZZ9ZkM dQkT7l0XhFvsgd8203/jV9aomod3dLAnoGsEIrs1TZ9Hpl5du4DckB/ARdTqwDVgzsWLHr6Y67 tWwyYdDLkkSO33BRYkgGGt6re0k5aIVCRH2hwyT0es1Ps4k/InGg7aFh2Oq+mAMeyFd8JmiuIm qB68yFBQ15tThkVXFBPk8oIg4eBhnOuBT6RTst58en6QyTNDcLnfON47XYD+hfdxLnJJCgT+hr i7U=
IronPort-HdrOrdr: A9a23:sRPgTqFcMXE3FwSrpLqENceALOsnbusQ8zAXPidKOHlom62j5q KTdZsgtSMc5Ax+ZJhCo7+90cC7KBvhHPVOkOos1NmZPTXOiS+HIIZv9oP+zzClMD2WzIJg/J YlV6RlEtX/ARxZgdaS2mOFOudl5NWc6qiniaPl0nF3QWhRBp1I9QtjFQqBKEFwSTRHAZZRLv Gh2vY=
X-IronPort-AV: E=Sophos;i="5.84,236,1620691200"; d="scan'208";a="9437925"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 13 Jul 2021 12:32:24 -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; Tue, 13 Jul 2021 12:32:24 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "paul.hoffman@icann.org" <paul.hoffman@icann.org>
CC: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [dns-privacy] [Ext] WG strategy on opportunistic vs authenticated moving forward
Thread-Index: AQHXeAKzBPkrW97l8U6Z4JY9euBbN6tBF1zw
Date: Tue, 13 Jul 2021 16:32:24 +0000
Message-ID: <768d9616b3474f6e9fd536f66aadd482@verisign.com>
References: <CADyWQ+FQsJmmqsVhBqxK6RP-0RhOHVqvMN_bQ4CEpBWNCU+LJg@mail.gmail.com> <929241ebd32b449bbaf5167ad17eafed@verisign.com> <3DAAA234-0447-4870-9DF3-A0A9B11392AD@icann.org> <89a17c65ff9a4708845d0fb57fd1d5cb@verisign.com> <13D06C82-0036-45FD-9E03-160D54D1FB66@icann.org>
In-Reply-To: <13D06C82-0036-45FD-9E03-160D54D1FB66@icann.org>
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/OXjRxTMwR0AFaK7LZxwVR6FxPDQ>
Subject: Re: [dns-privacy] [Ext] WG strategy on opportunistic vs authenticated moving forward
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, 13 Jul 2021 16:32:31 -0000

> -----Original Message-----
> From: Paul Hoffman <paul.hoffman@icann.org>
> Sent: Tuesday, July 13, 2021 12:18 PM
> To: Hollenbeck, Scott <shollenbeck@verisign.com>
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WG strategy on opportunistic vs
> authenticated moving forward
> 
> On Jul 13, 2021, at 8:56 AM, Hollenbeck, Scott
> <shollenbeck=40verisign.com@dmarc.ietf.org> wrote:
> > If a solution can be developed that works for all levels of the DNS hierarchy,
> fine
> 
> Are you saying that the current WG draft, draft-ietf-dprive-unauth-to-
> authoritative-03, doesn't work at all levels of the DNS hierarchy? If so, the
> specifics of that would be important for the WG to work on.

No, I'm responding to Tim's request for input: "We feel like the WG will not be able to make additional progress on any of the proposed solutions until we can reach consensus on whether the solution should be homogeneous from the root down or that the real focus is on SLDs and down."

SLD isn't quite right given that there are second-level domains that act like top-level domains, so I tried to be more precise by using "delegation-centric" instead. The service discovery part of any draft that requires publication of records in the parent could be an issue (as Tim noted), but beyond that I'm not specifically commenting on either of the proposed solution drafts.

Scott

v2.23.0 | Report a Bug | By Email