Re: [dns-privacy] [Ext] Moving forward on draft-ietf-dprive-unauth-to-authoritative
Bill Woodcock <woody@pch.net> Sun, 20 June 2021 12:48 UTC
Return-Path: <woody@pch.net>
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 1B2503A13A2 for <dns-privacy@ietfa.amsl.com>; Sun, 20 Jun 2021 05:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 bcivgbmbr9ib for <dns-privacy@ietfa.amsl.com>; Sun, 20 Jun 2021 05:48:30 -0700 (PDT)
Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03C83A13A3 for <dprive@ietf.org>; Sun, 20 Jun 2021 05:48:30 -0700 (PDT)
X-Footer: cGNoLm5ldA==
Received: from smtpclient.apple ([69.166.14.2]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Sun, 20 Jun 2021 05:48:03 -0700
From: Bill Woodcock <woody@pch.net>
Message-Id: <E4EEE5F4-E8E6-481E-B7DD-D15959D4475D@pch.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_100825D0-0D09-460D-936E-20B88A17DDFB"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Sun, 20 Jun 2021 14:47:59 +0200
In-Reply-To: <CABcZeBP2rASq+6bfpjh38msC3i+YUobbehyf7rD4fe=Xgxj_6Q@mail.gmail.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, "dprive@ietf.org" <dprive@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <9928187B-8A36-48BA-8C93-2E1A7EAAA2C2@icann.org> <CABcZeBN7b6iTS54oOKQT2SKT_+4TsAM5DkF3bjpSZKC2K+KzJw@mail.gmail.com> <834FE0FD-F720-4781-BD35-7B26E36D7DED@icann.org> <CABcZeBP2rASq+6bfpjh38msC3i+YUobbehyf7rD4fe=Xgxj_6Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/O-657La3etyV_Z0Qh-AuC8vYX_k>
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 12:48:35 -0000
> On Jun 20, 2021, at 3:40 AM, Eric Rescorla <ekr@rtfm.com> wrote: > In any case, to the extent to which the WG is going to work solely on the unauthenticated version, it can do so in the existing draft. Having a draft which purports to contain "common features" between the authenticated and unauthenticated use cases is not helpful when basic questions remain. My personal opinion is that unauth is a problematic half-measure, so I don’t imagine I’ll be using it. But that’s my personal opinion, and has no bearing on the question of whether the unauth mode should be formalized. If others see value in it, then, absolutely, it should be formalized so that a common understanding of how it should be done will exist, and interoperability will be maintained. Likewise, I REALLY WISH the authenticated mode would get moved forward more quickly. But tying the two together in any way at all seems bad to me. I don’t see any value at all to turning two documents into three, with externalities, nor, if only one of these modes becomes popular in the long run (which seems the most probably outcome to me) in having it be expressed in an incomplete document with an externality to another document which references a third document that nobody cares about. So I think I come to the same conclusion as ekr, albeit for different reasons. -Bill
- [dns-privacy] Moving forward on draft-ietf-dprive… Paul Hoffman
- Re: [dns-privacy] Moving forward on draft-ietf-dp… Eric Rescorla
- Re: [dns-privacy] [Ext] Moving forward on draft-i… Paul Hoffman
- Re: [dns-privacy] [Ext] Moving forward on draft-i… Eric Rescorla
- Re: [dns-privacy] [Ext] Moving forward on draft-i… Bill Woodcock