IETF Logo Mail Archive

Re: [DNSOP] Verifying TLD operator authorisation

Jim Reid <jim@rfc1035.com> Tue, 18 June 2019 14:12 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9D120046 for <dnsop@ietfa.amsl.com>; Tue, 18 Jun 2019 07:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 j2--7HwF60HH for <dnsop@ietfa.amsl.com>; Tue, 18 Jun 2019 07:12:14 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A2512001A for <dnsop@ietf.org>; Tue, 18 Jun 2019 07:12:14 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 1EE6324205E6; Tue, 18 Jun 2019 14:12:05 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <566ff2fe-1795-2046-8e23-46046bbf7385@time-travellers.org>
Date: Tue, 18 Jun 2019 15:12:04 +0100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <727C6E9D-F6D9-4E84-8347-6814C8AC176C@rfc1035.com>
References: <CAFz7pMvkQUz78Qow03RsFKHof3nrnGu3BUwUP0zstWgVtP3Msw@mail.gmail.com> <tqjbSfSi2Kv3DHpi6nBJVi2e6tCZFTdVyrKpxiud2348@mailpile> <4353B4DB-3F05-44B7-8272-A07EAF73B009@rfc1035.com> <566ff2fe-1795-2046-8e23-46046bbf7385@time-travellers.org>
To: Shane Kerr <shane@time-travellers.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fmOygIV-jS-OO9c6EmTvl4UzovI>
Subject: Re: [DNSOP] Verifying TLD operator authorisation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2019 14:12:16 -0000


> On 18 Jun 2019, at 14:56, Shane Kerr <shane@time-travellers.org> wrote:
> 
>> Being able to control a zone’s SOA record (or whatever) means just that. No more, no less. It doesn’t mean someone who has that ability also has the authority to change the zone’s delegation even though they can manipulate the zone contents.
> 
> You're basically arguing against ACME-style authentication.

Shane, I’m not doing that. At least I don’t think so.

ACME-style authentication is a very good thing, provided its limitations are understood. Using that to demonstrate ownership or control of some zone is not unreasonable. However using ACME-style authentication in that way doesn’t necessarily prove someone has the authority to change the delegation of that zone - more so when the zone is a TLD. All I’m saying here is it’s unwise to make that assumption or build a TLD delegation validation mechanism around it.

v2.23.0 | Report a Bug | By Email