Re: [DNSOP] ALT-TLD and (insecure) delgations.

Steve Crocker <steve.crocker@gmail.com> Fri, 03 February 2017 20:21 UTC

Return-Path: <steve.crocker@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 8256F1295D9 for <dnsop@ietfa.amsl.com>; Fri, 3 Feb 2017 12:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 il83kbrCFCEW for <dnsop@ietfa.amsl.com>; Fri, 3 Feb 2017 12:21:18 -0800 (PST)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 BBDA7129560 for <dnsop@ietf.org>; Fri, 3 Feb 2017 12:21:18 -0800 (PST)
Received: by mail-pf0-x241.google.com with SMTP id e4so2214563pfg.0 for <dnsop@ietf.org>; Fri, 03 Feb 2017 12:21:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KkNJk10FMDpQOj/5fQGxsWczoAWwnq0o0gY3ISH6q0I=; b=shDCNVTemwwEy/hG7Z8adVMUHmmdrRc/DZQJ6GovgXcjbmShqYwL6Vxi2PGj8/blR1 cKRzk6eRJ5aSAXrW7YNG2tNbz822TCtgfxfXmTWgbrPfQX4bXVE7CrfVI78UmCm5pLXU 72RV8U48euf28FGFYf4zp/mFF26vjw5Wgq8Vr8dXxnfPuVwY02tsDJkeM7UhEEoiuS6D kvbZHH5D++ccGmvNQd4UunLiAXnLrr3gBgtxalGvFf2hf3Y0r7hun+2q/ApuEbfvQBhQ KOCF6l6HYMVzCW0toi34s9Zd8F33x6pUgH2gpx3H8fSBmtsyNl6IWL7j2qMyBGBQDE9z vrHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KkNJk10FMDpQOj/5fQGxsWczoAWwnq0o0gY3ISH6q0I=; b=ZtBi2yU2VP3kXNRMcDQor7U5Len6c0zuaO47Oe35BwUBZyHb1dYoixCBBGClm8c/9y g4psMc7dVGQbidNhR6nK6Y7OkXVqckHboBhKUt/7YFz4BEJINXLrHDthcMnFkoBUUVdM 2+9to0EE3JNTld87DzhpYYRsWuYZA9WpxDOa5Lbs5HHQNNsU+Jg+QbDphPBvnKPs7GUR sH2dDWutl07R66uHVfiqtIQs7/D+1xNXKVxlkSM7z2XOP5HQK9+Fq6bqy3sWFYCRvhoa hFXYkHmM5oIv/uW9HQpLZut1G/yOw6VvyZ4AbQadaN+VRZCw4BsALiLpwthquvcCWDYD gzhw==
X-Gm-Message-State: AIkVDXJA8j4aIMFq4GmMH/3oPLYA/lfFD+CCtEF6UsLulw2WK5en8jsLjrcXnMXYogPh8Q==
X-Received: by 10.99.167.74 with SMTP id w10mr20737144pgo.2.1486153278292; Fri, 03 Feb 2017 12:21:18 -0800 (PST)
Received: from [172.16.144.233] ([69.31.123.67]) by smtp.gmail.com with ESMTPSA id b67sm69151131pfj.81.2017.02.03.12.21.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 12:21:17 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1EEEEC2D-AF0A-4971-BFAC-4EB2D2C4B355"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Steve Crocker <steve.crocker@gmail.com>
In-Reply-To: <CAH1iCiqMhky7r-kaMFTa41b2ZBfd3Fiffp0Rknx_4moaBx3t6w@mail.gmail.com>
Date: Fri, 3 Feb 2017 12:21:16 -0800
Message-Id: <74796240-46DA-4C8B-A715-DBC521EFA3F3@gmail.com>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <5FD13D0D-57DE-4CED-B1A2-C823079B8D63@gmail.com> <CAH1iCiqMhky7r-kaMFTa41b2ZBfd3Fiffp0Rknx_4moaBx3t6w@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TLyNvTgeCmaBWjrz6vHNPTXINNw>
X-Mailman-Approved-At: Fri, 03 Feb 2017 12:26:56 -0800
Cc: Steve Crocker <steve.crocker@gmail.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Feb 2017 20:21:20 -0000

And just to stir the pot a bit, what would you have ICANN do if someone applies for .alt as a top level domain?  Is it ok if we say yes and delegate the name?  If not, what is the basis for us to say no?


Steve Crocker
[I am having trouble sending from steve@shinkuro.com, but I am receiving mail without trouble.  Please continue to send mail to me at steve@shinkuro.com]

> On Feb 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> 
> The DNAME has an effect similar to delegation, except that in the case of the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 <https://tools.ietf.org/html/rfc7535> ) , the target is a well-known & published empty zone (as112.arpa.)
> 
> (Delegation and DNAME cannot coexist for the same owner name - that is one of the edicts for DNAME, similar to CNAME.)
> 
> Any local configuration of something.alt (as an authoritatively served zone) would be matched before checking the cache or attempting recursive resolution, per 103[345].
> 
> I don't have any desire or intention of local something.alt, I'm just pointing out that the existence of a signed NXD result (via DNAME to an empty zone) doesn't break such a set-up.
> 
> 
> 
> The reason for DNAME instead of delegation, is that it avoids the operators of AS112 instances from having to configure the new zone(s) whenever a new "delegation" occurs.
> 
> If, instead, a delegation were done, the specific zone (.alt) would need to be configured and served somewhere.
> 
> RFC7535 is designed to avoid the need for coordination in configuring such zones.
> 
> (RFC7535 also allows authorities for other places in the DNS tree to make use of AS112, but that is a non-sequitur.)
> 
> Brian
> 
> On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <steve.crocker@gmail.com <mailto:steve.crocker@gmail.com>> wrote:
> Are you also expecting ALT will never be delegated in the root?  If it were to be delegated in the root, what impact would that have on the uses you have in mind?
> 
> Steve Crocker
> [I am having trouble sending from steve@shinkuro.com <mailto:steve@shinkuro.com>, but I am receiving mail without trouble.  Please continue to send mail to me at steve@shinkuro.com <mailto:steve@shinkuro.com>]
> 
> 
>> On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com>> wrote:
>> 
>> Stephane wrote: 
>> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>>  Warren Kumari <warren at kumari.net <http://kumari.net/>> wrote 
>>  a message of 103 lines which said:
>> 
>> > or 2: request that the IANA insert an insecure delegation in the
>> > root, pointing to a: AS112 or b: an empty zone on the root or c"
>> > something similar.
>> 
>> Here, people may be interested by draft-bortzmeyer-dname-root (expired
>> but could be revived). The main objection was the privacy issue
>> (sending user queries to the "random" operators of AS112.)
>> 
>> My opinion on these issues are as follows, roughly:
>> I am in favor of AS112 for ALT
>> For AS112, I prefer the AS112++ method (DNAME)
>> I do not see why the DNAME would/should not be DNSSEC signed
>> Any local use of ALT can be served locally and signed using an alternative trust anchor
>> I don't think there is any issue with having both the NXD from the root, and the local assertion of existence, both present (in cache and in authoritative data respectively)
>> Maybe there are issues with specific implementations? 
>> If anyone knows of such problems, it would be helpful to identify them along with the implementation and version
>> For AS112 privacy, perhaps someone should write up a recommendation to set up local AS112 instances, to provide privacy, as an informational RFC?
>> Even simply through resolver configurations, without a full AS112 "announce routes"?
>> Do any resolver packages offer such a simple AS112 set-up?
>> Maybe the efforts for privacy should start there (implement first, then document)?
>> Do any stub resolver packages include host-local AS112 features/configurations?
>> Overall, I'm obviously in favor of use of ALT, and for signing whatever is done for ALT, and for use of DNAME for ALT.
>> 
>> Brian "DNAME" Dickson
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> 
> 
> 
>