[DNSOP] Re: everything bagels, Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)
John Levine <johnl@taugh.com> Wed, 11 June 2025 10:28 UTC
Return-Path: <johnl@iecc.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0D8CE339B2EC for <dnsop@mail2.ietf.org>; Wed, 11 Jun 2025 03:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b="nJ0HcLmg"; dkim=pass (2048-bit key) header.d=taugh.com header.b="VIXtypiC"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDvnBa5ClO8Q for <dnsop@mail2.ietf.org>; Wed, 11 Jun 2025 03:28:19 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 561C8339B2E4 for <dnsop@ietf.org>; Wed, 11 Jun 2025 03:28:19 -0700 (PDT)
Received: (qmail 71567 invoked from network); 11 Jun 2025 10:28:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=1178d68495a42.k2506; t=1749637688; x=1749983288; bh=BiDx/ecQ0H/Q3c25eGtdmKDGpB8gw95iW9L/K82NVY8=; b=nJ0HcLmgU8DyK9TBZHSU6cyXLsRkjRA1HYnvbATDNbYhn5U6n2NOkrFtIa60g0Bk3bIn9Hm8VFMo4h+pQaRS+JuYkmIQvHWMCpR9TLVtNYuI+oF4Hd0fyhqgvBKhjshbvT+XP6bENbZLihSgomAKVxrcopuBJVN1shzvwyMMHWSjV/Jf6v4N6vVYpW61tU6sCpaGW3VAAxIrk9KJ1NZdgaZCVqYq9+RgLqqKBLkUqaC2AyTQBTIQkNwZjYuLtAwpa18jxnJ/MmTiH8fKEjvDDkPoCec6T3/srz6TT7ehGqhG9kTAd4XL/CbRBlUJBEioiaFMYfyRIWpS/3OH6XHctg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=1178d68495a42.k2506; bh=BiDx/ecQ0H/Q3c25eGtdmKDGpB8gw95iW9L/K82NVY8=; b=VIXtypiCV/suyRpBjGOV3XazrAgvjttrGsjgdDEfInlPCL03/PZKZzP8LPm5rRj1aFcIo445jD2D5Bq7r/Z8aQuyZ+KZspYXXeZ0a282fUp5reBw2N0J/mUknSL2gsFxAaxYXsqCQxeXivOaVHBG6t4QY/owBcRd1kt+rXB07DpeGtzuAtfUBuVnSxRLElyR2d09KYAQ9OBKKGXNTMZFHfq5dOAGOrMJnM5IDMUSNRxEQk2D0ByZfv5vXAgIXvfdVwHPIOYyr0Ma/tIb6IApNRHtin5IIRo16ObDhF+nDOz6ytoGtfvktMWwjcUCon8VpbAzXFM0d9gE3fuLubop6Q==
Received: from ary.local ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA CHACHA20-POLY1305 AEAD) via TCP6; 11 Jun 2025 10:28:18 -0000
Received: by ary.local (Postfix, from userid 501) id 03EB3CDD0556; Wed, 11 Jun 2025 12:28:16 +0200 (CEST)
Date: Wed, 11 Jun 2025 12:28:16 +0200
Message-Id: <20250611102817.03EB3CDD0556@ary.local>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
In-Reply-To: <DM6PR15MB2361CDD15CABAEDA7CE91E45B36BA@DM6PR15MB2361.namprd15.prod.outlook.com>
Organization: Taughannock Networks
References: <CAKC-DJhS4_1P5Bqu-0YWWr9jkxBOt40rx5804UAUp7DhAsc31g@mail.gmail.com> <40408285-974A-4790-B653-DF4C3798F1E0@nohats.ca> <F7E48A3F-DA2C-4E54-92DA-90CD0EDE78DA@icann.org> <478e1879-93d4-4b0b-a99f-bbdb422bc073@taugh.com> <CAKC-DJh4ck_okAmdssMTfj5iq9X2o_-_Z6MzLQRSfZyjUJ3t6g@mail.gmail.com> <fcb3b846-7d2a-c567-2566-ba1614df31fa@taugh.com> <DM6PR15MB2361CDD15CABAEDA7CE91E45B36BA@DM6PR15MB2361.namprd15.prod.outlook.com>
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Message-ID-Hash: KT2KVEIHGOA6IYTF7HKXBVUR76OPDXCP
X-Message-ID-Hash: KT2KVEIHGOA6IYTF7HKXBVUR76OPDXCP
X-MailFrom: johnl@iecc.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: bemasc@meta.com
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: everything bagels, Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/P_obH4pyKuPVC6WxmJ1YOSUh2ts>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
It appears that Ben Schwartz <bemasc@meta.com> said: >-=-=-=-=-=- > >I think this PR is a fine direction, but it still seems to contain a certain amount of internal confusion. If the security "relies on the >causal relationship", then how can it be secure for persistent validation? What is the value of knowing that "either the DNS >Administrator of the domain has not chosen to remove the Validation Record or that a new owner of the domain has re-introduced the >Validation Record"? > >In my view, the core problem is that the draft is dancing around an unstated but essential requirement, for all DNS zones on the internet: > >0. We define Validation-Controlling Entries (VCEs) as any records or delegations at underscore-prefixed or wildcard names. >1. Zone owners MUST NOT allow other parties to add or modify a VCE unless the owner name's next label is uniquely assigned to that party. >2. Zone owners MUST NOT add a VCE without understanding and approving its function. >3. When acquiring a zone, the new owner MUST promptly remove all VCEs whose function is not understood and approved. I don't think any of this is wrong per se, but I also think it is vast overkill, the threats are largely if not entirely hypothetical, and this will add a lot of complication that distracts from the goal of this draft, to provide a consistent form for these records so you can tell where they're from and if they're likely still to be useful. For example: >3. When acquiring a zone, the new owner MUST promptly remove all VCEs whose function is not understood and approved. I dunno about you, but when I have bought or sold domain names, the transfer has never ever included a copy of the existing DNS zone. The new owner has new nameservers and sets up all new DNS. One time I persuaded a buyer to keep my MX for a while to help move mail users but that was a one-off and totally manual. While I believe that one might in theory do an on-path attack to do fake DCVs, unless someone can show some real examples I would not confuse people by talking about it. It's no different from faking any other DNS record. R's, John
- [DNSOP] Persistence of DCV, including for Delegat… Erik Nygren
- [DNSOP] Re: Persistence of DCV, including for Del… Ben Schwartz
- [DNSOP] Re: Persistence of DCV, including for Del… Paul Wouters
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Hoffman
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Wouters
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Erik Nygren
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Ben Schwartz
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Wouters
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Ben Schwartz
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Watson Ladd
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Erik Nygren
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Hoffman
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Ben Schwartz
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Hoffman
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Hoffman
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John R Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Joe Abley
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John R Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Wouters
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John R Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Erik Nygren
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Wouters
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Paul Hoffman
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John R Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Erik Nygren
- [DNSOP] Re: [Ext] Persistence of DCV, including f… John R Levine
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Ben Schwartz
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Erik Nygren
- [DNSOP] Re: [Ext] Persistence of DCV, including f… Ben Schwartz
- [DNSOP] Re: everything bagels, Persistence of DCV… John Levine
- [DNSOP] Re: everything bagels, Persistence of DCV… Ben Schwartz
- [DNSOP] Re: everything bagels, Persistence of DCV… Erik Nygren
- [DNSOP] Re: everything bagels, Persistence of DCV… John R Levine
- [DNSOP] Re: everything bagels, Persistence of DCV… Paul Wouters