Re: [DNSOP] [Ext] Possible alt-tld last call?

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 24 October 2022 20:23 UTC

Return-Path: <brian.peter.dickson@gmail.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 0BC34C1524B6 for <dnsop@ietfa.amsl.com>; Mon, 24 Oct 2022 13:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7PyjCEyQhvq for <dnsop@ietfa.amsl.com>; Mon, 24 Oct 2022 13:23:25 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15111C1524C1 for <dnsop@ietf.org>; Mon, 24 Oct 2022 13:23:14 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id n73so8656976iod.13 for <dnsop@ietf.org>; Mon, 24 Oct 2022 13:23:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IqJlOJpzl9dROW3u3P+PPrE301qM8c8lGV40hAnIt4w=; b=LkEnXNT+oDNgkp3PeBWKZJPn+4S2bDBSTGJRdsZD+XoevntPtxrjPzaOLqsHuifNld TvyFbvsuAo/yrj3hSo5vboWMCQyx/QnIeX9bUlghJFHWWUjZ4eOg4nNYsu0e9YcQhma7 VOLhThhN57642KyVaxmUqssluykbK02I7jdtsa+t1lMP/WiV/UPcrmcUe4w3qxUIEUXT GcGbTznxnn1p7f/e2g20XjBiYKFTEZVJfOCyqMD3oUUCm8hqlzo2ao3JLhfhcMjpHFtE g/cfAdHmZVFGsz/JEMc2iApSrJMvskCGwenVrElJO3Y0KllJDPM8hDf3EqeIO0ttmy77 +B1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IqJlOJpzl9dROW3u3P+PPrE301qM8c8lGV40hAnIt4w=; b=3jPrvdfG+zixLnEoM9FOt/HO8s3/p34xJF1bdeR5ZubyWWPPMG12cd+sm7rooHTILV YfQk3Ca0XdbFiwx23lEJXtIYx9kDH6li8S5nblyrSAJ0LtD+aey050dMJNEeYSFV95uJ ZU3SFwI5JluEKpnSySy8ogas5rFmlGDJKJPWbhjBYGb/j1J8RnBlgOq8h7K6bxS7mX4H LaFnmUhtvuapCHnVclmQE/IkSgwlqaCxZrvKTKLwBG0BCdLqGGDTxkfClvnNuxgNaqqC 0zB6MCl13WH7cnngmyB7vud/QUtKHHsmRXmcg3iNukjmDwh3VQg7rKxjiLjeK93OFhJR WZ8A==
X-Gm-Message-State: ACrzQf2uhKz+9ipz7WWedMnm/9dHq7m9hco2Dbiv+9wAYe0l4wBmyKr0 ROXCRmg3Mw091BKRTTvKDcnxd2rdswQ8frwh+opplwt4
X-Google-Smtp-Source: AMsMyM62ox/sQHBz7koTdSbY/UY3A899B1D8e0EWlxta3u7CGy7wdVssNKU17AAhpYJ94LWPbmxGW+Ui2bwjbc89onE=
X-Received: by 2002:a05:6602:2e06:b0:6bf:f653:d1af with SMTP id o6-20020a0566022e0600b006bff653d1afmr1073736iow.27.1666642993235; Mon, 24 Oct 2022 13:23:13 -0700 (PDT)
MIME-Version: 1.0
References: <D4D1C61C-6DAF-4D02-A861-D808270687B0@pir.org> <F514B317-18E8-4EEC-8049-A5BCAB4EB6B6@icann.org> <7A6FC59E-590C-411F-A83C-26E12172FB43@virtualized.org> <8B1A1AA1-A19E-4D26-8DB3-52B377EDA140@icann.org> <48CA0E74-2103-4691-9AC5-AB3E3360573A@virtualized.org> <9EB3910D-9ACE-476E-AEB6-798B9E5321FF@icann.org> <6471571B-0DC3-4978-8177-AEBE590C2085@virtualized.org> <BY5PR11MB4196CCA9F8FC2AE3679E6C57B52C9@BY5PR11MB4196.namprd11.prod.outlook.com> <7F3255E1-054D-4CA2-98CE-7518A0FBBE77@virtualized.org> <MN2PR11MB42079F9F77ECA7644458853EB52C9@MN2PR11MB4207.namprd11.prod.outlook.com> <CF130BA4-2FF8-4257-9B5F-3886851AC019@virtualized.org> <0809cd98-9d13-de7f-6522-bd9547c5e4b2@redbarn.org> <CAH1iCipNcsFnCSu338o3gfgfXyT5=r+=uvgbHKkSWL8F=ak7eg@mail.gmail.com> <221db3c6-1cf0-f954-b87-aec0d0a6d55a@nohats.ca>
In-Reply-To: <221db3c6-1cf0-f954-b87-aec0d0a6d55a@nohats.ca>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 24 Oct 2022 13:23:01 -0700
Message-ID: <CAH1iCip9_5ZKL761NN0mL714H3+9VUPNHA3i+vYD68E=Qp32HA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009450ea05ebcd8f98"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0xL0V_VxXzv5dDcQAsI_bB4YXGY>
Subject: Re: [DNSOP] [Ext] Possible alt-tld last call?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 24 Oct 2022 20:23:30 -0000

On Mon, Oct 24, 2022 at 12:45 PM Paul Wouters <paul@nohats.ca> wrote:

> On Mon, 24 Oct 2022, Brian Dickson wrote:
>
> > Just to expand on this idea (which I quite like), the original AS112 was
> enhanced to handle new/arbitrary names, so
> > that AS112 operators don't need to do anything to support being a sink
> for new domains.
> >
> > This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
> target for use via DNAME.
> > (The DNAME bit is so there isn't a delegation for which the AS112
> operator would need to have a zone configured.)
> >
> > Using this via the root zone would be a new kind of entry for the root
> zone, but is otherwise non-controversial
> > (IMHO).
> > It would basically look like:
> >       alt. DNAME empty.as112.arpa
>
> this is dangerous. Anyone who runs an as112 node, or an attacker who
> compromises one, can then serve a "real" .alt to a percentage of
> queriers. Imagine millions being lost in some cryptocurrency .alt
> non-dns scheme.
>
>
This is accurate. It is dangerous to other namespaces if they don't take
appropriate safeguards.

What this points out is that ".alt" is intended to protect DNS (at the root
at least) from the effects of other namespaces.

It is not (or at least has not been explicitly established for) use by
other namespaces to protect themselves from errors like this.

In the jargon of mathematics, "alt" is necessary, but not sufficient.

Any namespace that would fall under the "please use .alt" umbrella, would
be wise to build into the protocol(s) or implementation(s) some guard-rails
against leakage.

So, another reason for "MUST NOT", but perhaps out of scope for dnsop
itself to say (other than to indicate,  "here be dragons".)

Brian