Re: [DNSOP] Verifying TLD operator authorisation

Nick Johnson <nick@ethereum.org> Fri, 14 June 2019 02:38 UTC

Return-Path: <nick@ethereum.org>
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 3DC831200D6 for <dnsop@ietfa.amsl.com>; Thu, 13 Jun 2019 19:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ethereum.org
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 RSaAM-DFYOiz for <dnsop@ietfa.amsl.com>; Thu, 13 Jun 2019 19:38:26 -0700 (PDT)
Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C51120018 for <dnsop@ietf.org>; Thu, 13 Jun 2019 19:38:25 -0700 (PDT)
Received: by mail-ed1-x541.google.com with SMTP id k8so1145722edr.11 for <dnsop@ietf.org>; Thu, 13 Jun 2019 19:38:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ethereum.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=scbnNYdTyC6KlzM+IDkpxzF7VWe4qqEycwWqYuZ3zfU=; b=Gku8ZTDoX2Urgu+TuYCscUbGHjRfMpSe1Dev9TA/H9ZTXevQ8n/oOTkBjIoWwXXDWU AroWXxPM4jgqJd3qBqpx6eKYYI4gtNaGzcYgwAEj13J8g+KEyXBIvytk3omdlQ9G3fs8 XV3qhLmzVp2vJ62pA56OW0S+Oj0cO+vmsFRdU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=scbnNYdTyC6KlzM+IDkpxzF7VWe4qqEycwWqYuZ3zfU=; b=JH1ApWRSLYcWiVUT4t8ezI8EjsDgkMp+y1BmETGd+SzL7QKJubjrCbhlNab9QhEa2D /eO4haaZVYMirICGeZ9MEj5YU9H3zE8N2+ld+Cw9KxYohu8wKy7b0K0/D5kEiY+yJtZB FONVjw3ltYPNNSuha/NONKjy8IYAkJ5W1Ct/rkvEHoJRUcCwqS8b1MwViUxa62ZmmGmu a4hnCrol/wy2voEhNsyHvZuB0/9GTT2nfrxw3K0wU3SrREcaEX/4dPdD8ZkijGSr5/Hy ZKiKkb9789dcAWrVStRLRu+dkVwM5vwbveJyTYnga+JFdEMPqJmnBxzyG4QQXTFLV/lX R/PA==
X-Gm-Message-State: APjAAAWBskgkE1SQ9AyPxfv14OjhNEeLBU9KcCuBB9FCjIoPq6FRHMLK Fi0dZxqZHFbE0Q+MnaB2XOQJTJd8A3O2XzUL3FmKcfIrzySUcA==
X-Google-Smtp-Source: APXvYqzo0rrEFrmINCH9dKcZtmwEJXXilJfg9Wh7Lbuu8GhP7OM7yKN/GGKVPW0t6xnZADhzC7KBoycltsGgvwUAsdY=
X-Received: by 2002:a17:906:5047:: with SMTP id e7mr70675760ejk.282.1560479904191; Thu, 13 Jun 2019 19:38:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAFz7pMvkQUz78Qow03RsFKHof3nrnGu3BUwUP0zstWgVtP3Msw@mail.gmail.com> <CAJhMdTPTY7DmXPtTbAVCd+HNUgj9NkQoXyqa3Yx3LBJnQ+DwrA@mail.gmail.com>
In-Reply-To: <CAJhMdTPTY7DmXPtTbAVCd+HNUgj9NkQoXyqa3Yx3LBJnQ+DwrA@mail.gmail.com>
From: Nick Johnson <nick@ethereum.org>
Date: Fri, 14 Jun 2019 14:38:11 +1200
Message-ID: <CAFz7pMvmMw4nE5Wb1TUL+qkfwnUJeU3AAGeuGeD9WJwpE5fFGQ@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005e6bf0058b3f8a68"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KRuA1lqAs2Rlmx8HMONr7jhSXMY>
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 02:38:28 -0000

On Fri, Jun 14, 2019 at 2:30 PM Joe Abley <jabley@hopcount.ca> wrote:

> On Jun 13, 2019, at 22:18, Nick Johnson
> <nick=40ethereum.org@dmarc.ietf.org> wrote:
>
> > I'm working on a system that needs to authenticate a TLD owner/operator
> in order to take specific actions.
>
> Can you give an example of the actions?
>

We build and maintain ENS, a naming system based on the Ethereum
blockchain. We're building a DNS integration that will permit any TLD
operator to claim and operate that TLD inside ENS. To do that, we need some
way for the owner or operator of the TLD to assert a public key that should
have control of the TLD in our system.


>
> When you say "owner/operator" what exactly do you mean?
>

Any party authorised by the TLD owner to take actions on their behalf. The
right to publish records to their zone, or to sign messages with their zone
key, seems like a reasonable proxy for that.


> > We had intended to handle this by requiring them to publish a token in a
> TXT record under a subdomain of nic.tld, but it's been brought to our
> attention that we can't rely on nic.tld being owned by the TLD operators -
> this is only a reserved domain on ICANN new-gTLDs, not on ccTLDs or older
> gTLDs.
>
> Right.
>
> > An alternative is to require a message signed by the TLD's DNSSEC zone
> signing key, but I'm uncertain whether it's practical for TLD operators to
> sign arbitrary messages using their keys.
>
> It does sound like a bit of a stretch. Also, not all TLDs are signed,
> and some of those that are have KSKs that are constrained by process
> as to how they can use, so using them for a new purpose might be
> expensive.
>

We're okay for now with not supporting unsigned zones, but the latter seems
like a definite issue. I don't have a lot of insight into how TLD operators
handle their signing keys, and I'm hoping others here can offer more
details on how difficult this might be.


>
> > Are there domains that are globally reserved for the operator across all
> TLDs?
>
> The zone apex is the only owner name you can rely upon always
> corresponding to a particular TLD, but don't expect it to be simple to
> publish new and exciting things there in all cases.
>

Indeed - it's my understanding that ICANN forbids publishing anything to
the root zone other than necessary records such as SOA, NS and DNSKEY.


> > If not, does anyone have any recommendations on an alternative
> authorisation or authentication mechanism?
>
> It's hard to make a useful suggestion without understanding what
> you're trying to accomplish.
>
>
> Joe
>