Re: [DNSOP] Verifying TLD operator authorisation

Joe Abley <jabley@hopcount.ca> Wed, 19 June 2019 22:45 UTC

Return-Path: <jabley@hopcount.ca>
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 80C6E1205B4 for <dnsop@ietfa.amsl.com>; Wed, 19 Jun 2019 15:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 NEtzsKFLfTRu for <dnsop@ietfa.amsl.com>; Wed, 19 Jun 2019 15:45:45 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 18B48120048 for <dnsop@ietf.org>; Wed, 19 Jun 2019 15:45:45 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id c70so645980qkg.7 for <dnsop@ietf.org>; Wed, 19 Jun 2019 15:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gb5e7fk63TBp36+pbHm8bucIdmogs1Rz/Og+2jCCerI=; b=D78beUloTrsoj1jEx/sSK63k02f4PfPhdPhvvBMC+pWZdXT/2c0d6tA4v3BQ6gqe+4 dS8cxJKhr5NEAy8D9nsGEuJf9IW9nOISkS0tphOTvSZ+XTCISzwNauvi5GwgGN7n0pwJ tL89YeYNonLb+rJV0mqFJCogyRvlA6/3UYO/g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gb5e7fk63TBp36+pbHm8bucIdmogs1Rz/Og+2jCCerI=; b=FLt35thfsxK2EMnRjNoPVSIfuIGrMqsugpjFpaABJ4iZqhNvLUUOO1ujBcZfx1L1vk OvXsp6tWk3luK1ZyCMQch3pKse4UqmyOS5XSv4jh9V15Q4Fc4Y/dUDvNdCjP7V5sDhvC H7RDI0rzP7COP0210EEIxeBlvegMW7O/MucCzqWpostdBld+SaTmxO5RMfRqU7NNpqQP mgNZAih/rqNWDAE52l3aSjCSZSv7t4FOKUxlWM9mEfX1WNbfOP3h6Jw7cvSln7gXivzW bblo/9xkdjTAqxjKpf97KMiojIeZxr3+ohjZS6f4Cx6FxaPg+61cPq5k0PUrk3RIi89X 09xw==
X-Gm-Message-State: APjAAAX4rPe9KyPYTVnWUHpEd9mpOM5wwNxZWCFPn3agfLv8c5TvRJBv BAOcVmLTgXP//qebYPndQQPeAPUhwp5pdPY/
X-Google-Smtp-Source: APXvYqzrlH8qsmnUs4wgUltoOlb9t/P39kyqVVVfiIEpyM3KTO3mZlG0kemBNQ0huNUOiRO1XOinxQ==
X-Received: by 2002:a37:b8c:: with SMTP id 134mr69257053qkl.160.1560984344031; Wed, 19 Jun 2019 15:45:44 -0700 (PDT)
Received: from [192.168.1.50] (198-84-196-112.cpe.teksavvy.com. [198.84.196.112]) by smtp.gmail.com with ESMTPSA id u7sm13995336qta.82.2019.06.19.15.45.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 15:45:42 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <95F7D9FF-D403-4638-B3C3-79D1EDC34054@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_AAAFDD04-1AC3-489A-A5C7-1E65E8D84E9A"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 19 Jun 2019 18:45:40 -0400
In-Reply-To: <CAFz7pMsAZvUybb=i50s4woCacZiFY938s-UVb5rMPSC-Fx27pw@mail.gmail.com>
Cc: Jim Reid <jim@rfc1035.com>, dnsop WG <dnsop@ietf.org>, Bjarni Rúnar Einarsson <bre@isnic.is>
To: Nick Johnson <nick=40ethereum.org@dmarc.ietf.org>
References: <CAFz7pMvkQUz78Qow03RsFKHof3nrnGu3BUwUP0zstWgVtP3Msw@mail.gmail.com> <tqjbSfSi2Kv3DHpi6nBJVi2e6tCZFTdVyrKpxiud2348@mailpile> <4353B4DB-3F05-44B7-8272-A07EAF73B009@rfc1035.com> <CAFz7pMsAZvUybb=i50s4woCacZiFY938s-UVb5rMPSC-Fx27pw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3TSsDb-HsBKij2j-giaV47tDvGo>
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: Wed, 19 Jun 2019 22:45:48 -0000

On 19 Jun 2019, at 18:28, Nick Johnson <nick=40ethereum.org@dmarc.ietf.org> wrote:

> On Tue, Jun 18, 2019 at 10:15 PM Bjarni Rúnar Einarsson <bre@isnic.is <mailto:bre@isnic.is>> wrote:
> The SOA record for a TLD contains two DNS names which should be
> under the control of the NIC: that of the primary master
> nameserver, and the e-mail of the responsible administrator
> (which includes a domain name).
> 
> This seems like an excellent idea - thanks! I'll wait to see what others have to say.

I think you could probably build a heuristic around MNAME and RNAME that would work at least most of the time. However, there's no definitive identifier and there will always be exceptions you have to work around. Sometimes MNAME relates to a back-end registry provider, sometimes to a registry operator, and sometimes something else entirely. Ditto RNAME.

> I think I addressed this upthread: If someone has the ability to change a zone's DNS records and generate valid DNSSEC signatures for them (which we will be requiring and verifying), they're sufficiently 'in control' of the zone that I'm comfortable treating them as the authorised user. If someone malicious has that control, the TLD owner has much larger problems.

The organisation that generates the SOA/NS/A/AAAA RRSets in a delegation-only TLD zone is not always the same organisation that signs it. Also, not all signatures in a zone can be guaranteed to have been created by the same organisation. Also, not all TLDs are signed.

The contacts that the IANA relies upon to authorise changes for TLD operators can be found at whois.iana.org <http://whois.iana.org/>, for what that's worth, or in due course at the RDAP server specified in the object <https://data.iana.org/rdap/dns.json <https://data.iana.org/rdap/dns.json>>. But if you're looking for something reliable you can validate using DNSSEC, I think you're out of luck.


Joe