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

Suzanne Woolf <suzworldwide@gmail.com> Sat, 04 February 2017 13:45 UTC

Return-Path: <suzworldwide@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 DB9F3129634 for <dnsop@ietfa.amsl.com>; Sat, 4 Feb 2017 05:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_Cmayq_g51F for <dnsop@ietfa.amsl.com>; Sat, 4 Feb 2017 05:45:28 -0800 (PST)
Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 2C478129A86 for <dnsop@ietf.org>; Sat, 4 Feb 2017 05:45:28 -0800 (PST)
Received: by mail-qk0-x244.google.com with SMTP id u25so2473106qki.2 for <dnsop@ietf.org>; Sat, 04 Feb 2017 05:45:27 -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=UbICaGcK8Cw23PMEp8cAR+mZNw0qOe+f1rbx9M58fRQ=; b=T/BiK2YLVkwIMvBB2oQuZ5Y8uBX8Os64/pWHIOZZcwaV0As7ssGYpMySM5S6puf5uP l6c19L5tVKlj4sAZ3bBo3lVYecvlbXjN8RWVLQHSX5GcMKbrgzdszstsPEw3abXrvl82 7Jt/MLfEprEFSsBcXHl7fXcHLWW51jcNcNfIA9NsuxUTkp2tFPF8ev1KVz4vivB9YwYk 3wT6+WwpK95TrTZrlyG2yHst1mBtDUNUAAtIO9lVolm+Q8khAV8mZU+Z02A6RdkkeorM 2KJQoRlIUmcvFmx623m4AjA7vgALNIXsx/7ZH0bfFCTHeWMqimeYcMvY1NvqZ+qE+V0s q0EQ==
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=UbICaGcK8Cw23PMEp8cAR+mZNw0qOe+f1rbx9M58fRQ=; b=SHaCUBKyzgyoIWU6/7KspKA3qK9I/1d89aYIoN4dHBsyZllvKkn1s4Dd/8uVez/fmc kgqtp7JnZ1T+2X3LBuvD/wH69twOmc4Mvk0lp71C6T+Fropti4SgoOIrm45lFRyl6tPM m/70IYu/LbRzNL6IEpBMP43y5EZQ9wAnh0bTPs828gMmH26LPZ5QNLDBEyqQzTNM1uw8 KAHhqBR35g+fCjpmvOf+2+Ny9QbFWMDuga+b1zyKuyMIbhhs2UyDyPRjE1rZKC4WB0Qf 1O1VfRZMvTtkvszUzDX9oU6AMN5VbnDuwbmC3ELauDhicYRar5tHWjdpP42dga1+CrBd gU4g==
X-Gm-Message-State: AMke39kf8xF05UwwQikocJzzD7jzpLW9QxnWJs+nzne1FCnnqFGn2PFsRWPyyWfs4fCLKg==
X-Received: by 10.55.104.79 with SMTP id d76mr2159559qkc.114.1486215927042; Sat, 04 Feb 2017 05:45:27 -0800 (PST)
Received: from [10.0.0.19] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id k19sm27511113qtf.37.2017.02.04.05.45.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 04 Feb 2017 05:45:26 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_99A4C4ED-23E3-4594-914D-F0D23791BCA4"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com>
Date: Sat, 4 Feb 2017 08:45:23 -0500
Message-Id: <81B466E3-D82D-4DC0-8307-23DC3236D3C5@gmail.com>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <9B6211A9-20B5-4B15-A8FD-A1390DAD76AE@fugue.com> <20170203224708.A0EE061891C7@rock.dv.isc.org> <5EAC5DDC-7B93-40B5-B28D-150DAABE4BAC@fugue.com> <20170204021009.GE67739@mx2.yitter.info> <88686BFE-7874-4EB4-8E04-FF68DFB51F94@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fTFVfPWe7YoOmPpDs92fo9X1KGM>
Cc: dnsop@ietf.org, Andrew Sullivan <ajs@anvilwalrusden.com>
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: Sat, 04 Feb 2017 13:45:30 -0000

> On Feb 3, 2017, at 9:40 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
>> My memory is that only after that
>> did we start thinking of a sort of 1918-style part of the DNS as
>> well.  That may have been a mistake, since as this discussion is
>> showing the properties of an in-protocol, in-DNS namespace without
>> delegations are somewhat different to alternative-protocol uses that
>> do not rely on the DNS at all.
> 
> I think that we've seen a number of questions go by that lead to the conclusion that it makes sense to have two hierarchies: one for experimental non-DNS queries, and one for locally served zones.   I don't know if we _need_ the .LSZ (or whatever) SUTLDN, but if we need to be able to have a special-use top-level domain name that has an un-signed delegation, it probably ought to be different than the SUTLDN that is used for non-DNS stuff, so that both names can have the appropriate configuration in the root zone.

We may be making this harder than it has to be.

It’s worth noting at this point that the "1918-style part of the DNS” (DNSSEC compatibility for names intended to be locally resolved with the DNS protocol) is a solved problem, if you mean it literally: they’re under .arpa.

This was an obvious solution for address blocks, since in-addr.arpa was already established by the protocol for PTR records and .arpa was already administered under IETF rules.

However, in terms of the desired behavior all the parts are there: .arpa is a signed zone, can have signed or unsigned delegations for names intended to be resolvable in the DNS (locally or globally), and is administered under IETF rules that include *not* delegating special use names under it that shouldn’t be in the DNS (I don’t see the IAB having a problem with making a commitment that a specific string won’t be delegated).

The objections to .home.arpa were to the specific string “.arpa” and that it wasn’t a single-label name, which seemed to be strong preferences but I’m not sure were ever documented as hard (“it won’t work otherwise”) requirements. For other special use names, they might very well not be constraints.

Having already decided that “single label” is a tough constraint to maintain if you want an unsigned delegation from a signed zone (i.e. an unsigned TLD in the root), I’m not sure I see a major difference between mystring.alt and mystring.arpa.


Suzanne