IETF Logo Mail Archive

Re: [DNSOP] Verifying TLD operator authorisation

Jim Reid <jim@rfc1035.com> Fri, 14 June 2019 13:23 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 181EE1200CD for <dnsop@ietfa.amsl.com>; Fri, 14 Jun 2019 06:23:48 -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 UiFs6VQx_mqZ for <dnsop@ietfa.amsl.com>; Fri, 14 Jun 2019 06:23:46 -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 711D412001A for <dnsop@ietf.org>; Fri, 14 Jun 2019 06:23:46 -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 D910424205E6; Fri, 14 Jun 2019 13:23:43 +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: <784348a0-b064-d66e-627d-80617ba468b1@lisse.NA>
Date: Fri, 14 Jun 2019 14:23:43 +0100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <302BDDF8-B18C-40C1-A5A4-B88C38767015@rfc1035.com>
References: <CAFz7pMvkQUz78Qow03RsFKHof3nrnGu3BUwUP0zstWgVtP3Msw@mail.gmail.com> <0202F994-3BFF-4FA5-A187-C0B3E8E1E108@rfc1035.com> <784348a0-b064-d66e-627d-80617ba468b1@lisse.NA>
To: el@lisse.NA
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XZ3MUkXEvQ61amZAvlEBDH7rHNI>
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: Fri, 14 Jun 2019 13:23:48 -0000


> On 14 Jun 2019, at 14:13, Dr Eberhard W Lisse <el@lisse.NA> wrote:
> 
> Would (GPG encrypted) email to the registered address to the authority
> not be sufficient?  That would make sure the recipient is authorized and
> must then cause the token to be 'delegated' as the second factor.

If there was a secure* channel between the TLD registry and IANA like the GPG email you suggested, there wouldn’t really be a need to insert and check for some token in the TLD zone. Though as you say, that measure might be a useful way of adding 2FA.

* For some definition of secure.

In any case, I’m not sure this list is the right place to define or develop a solution for this issue. We probably don’t have a complete understanding of the problem space or the details of how IANA and TLD registries/SOs communicate with each other, what the requirements are, etc, etc.

v2.23.0 | Report a Bug | By Email