Re: [dns-privacy] [Ext] Moving forward on draft-ietf-dprive-unauth-to-authoritative

Paul Hoffman <paul.hoffman@icann.org> Sun, 20 June 2021 01:24 UTC

Return-Path: <paul.hoffman@icann.org>
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 E48723A120D for <dns-privacy@ietfa.amsl.com>; Sat, 19 Jun 2021 18:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ni9VlbVtsfIo for <dns-privacy@ietfa.amsl.com>; Sat, 19 Jun 2021 18:24:35 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 370E73A120B for <dprive@ietf.org>; Sat, 19 Jun 2021 18:24:35 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 15K1OXbG011917 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dprive@ietf.org>; Sun, 20 Jun 2021 01:24:34 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12; Sat, 19 Jun 2021 18:24:33 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0858.012; Sat, 19 Jun 2021 18:24:33 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dprive@ietf.org" <dprive@ietf.org>
Thread-Topic: [Ext] [dns-privacy] Moving forward on draft-ietf-dprive-unauth-to-authoritative
Thread-Index: AQHXZXMGAzwX2Tjo3EyyoyO4yorfyw==
Date: Sun, 20 Jun 2021 01:24:33 +0000
Message-ID: <834FE0FD-F720-4781-BD35-7B26E36D7DED@icann.org>
References: <9928187B-8A36-48BA-8C93-2E1A7EAAA2C2@icann.org> <CABcZeBN7b6iTS54oOKQT2SKT_+4TsAM5DkF3bjpSZKC2K+KzJw@mail.gmail.com>
In-Reply-To: <CABcZeBN7b6iTS54oOKQT2SKT_+4TsAM5DkF3bjpSZKC2K+KzJw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_795D5BF7-5964-42E5-B689-89C45C97AB61"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-19_14:2021-06-18, 2021-06-19 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/GtLV_d9qIQFzWCj6WmMBrOwEWCw>
Subject: Re: [dns-privacy] [Ext] Moving forward on draft-ietf-dprive-unauth-to-authoritative
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: Sun, 20 Jun 2021 01:24:40 -0000

On Jun 18, 2021, at 7:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
>> On Wed, Jun 16, 2021 at 10:13 AM Paul Hoffman <paul.hoffman@icann.org> wrote:
>> Greetings again. Based on the WG discussion of the last few weeks, we can see that the folks with the fully-authenticated use case do not yet agree on a signaling mechanism. Given that, we have just published a new version of draft-pp-dprive-common-features that lists "SVCB on the client side" as one discovery mechanism, and a new version of draft-ietf-dprive-unauth-to-authoritative that points to that mechanism. When the folks with the fully-authenticated use case do agree on a signaling mechanism, that can be added to the -common-features draft.
>> 
>> We would like the WG chairs to have a formal call for draft-pp-dprive-common-features to be a WG document soon so we know how to deal with it before the draft cutoff before the next IETF meeting. If the WG wants it as a WG document, great; if not, we would pull back all those features into draft-ietf-dprive-unauth-to-authoritative and the WG would have to decide what to do for the eventual fully-authenticated draft.
>> 
> I think (unsurprisingly) I am not in favor of this. Let's figure out what we are trying to do and roughly the approach we want to follow. Until then, adopting drafts is premature.

The WG can work on the already-adopted unauthenticated use case, and the fully-authenticated use case can catch up when there are authors interested in keeping the discussion on their protocol moving.

--Paul Hoffman