IETF Logo Mail Archive

Re: [dns-privacy] [Ext] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

Paul Hoffman <paul.hoffman@icann.org> Wed, 26 May 2021 00:17 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 9DA7C3A1410 for <dns-privacy@ietfa.amsl.com>; Tue, 25 May 2021 17:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 woCh3yWAoS52 for <dns-privacy@ietfa.amsl.com>; Tue, 25 May 2021 17:17:41 -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 5B4D93A11F2 for <dns-privacy@ietf.org>; Tue, 25 May 2021 17:17:41 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 14Q0Hd6u026588 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dns-privacy@ietf.org>; Wed, 26 May 2021 00:17:40 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12; Tue, 25 May 2021 17:17:39 -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; Tue, 25 May 2021 17:17:39 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: DNS Privacy Working Group <dns-privacy@ietf.org>
Thread-Topic: [Ext] [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features
Thread-Index: AQHXUcSJRWhsmeS7IUi1J4ixizJQIA==
Date: Wed, 26 May 2021 00:17:38 +0000
Message-ID: <3761A6B3-A53F-4B63-8F7A-FA2B3F474FF3@icann.org>
References: <CADyWQ+E9jpV0BwMsaS8=vNbs7x87d4qqGbKQevj8MVGCLGyv5w@mail.gmail.com> <21CD5432-D523-4316-A5D0-E5ECA4D84F7E@nohats.ca> <CABcZeBM+zng4vTXwgTH328O-LPy9VLGPOrGK_UWtiXGQCYeZzw@mail.gmail.com>
In-Reply-To: <CABcZeBM+zng4vTXwgTH328O-LPy9VLGPOrGK_UWtiXGQCYeZzw@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=_A4D40E37-52FA-4F2B-A40C-695AB9F1E027"; 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.761 definitions=2021-05-25_09:2021-05-25, 2021-05-25 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/SE2vP_r6V9pIeFWFbux3TObyK0U>
Subject: Re: [dns-privacy] [Ext] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 26 May 2021 00:17:46 -0000

On May 25, 2021, at 5:09 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> The fundamental question here is whether we want to build a mechanism for authenticated ADoX or not

It might be better to think of this as "whether we want to build a mechanism for fully-authenticated ADoX now, but if not now, allow for it to be done easily in the future". Others on the list have already said that they are interested in unauthenticated as a stepping stone to later going to full authentication.

The purpose of the proposed -common-features draft is to make such fully-authenticated mechanism(s) easily definable regardless of when the WG wants to do so.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email