Re: [homenet] On the TLD question and validatably-insecure delegation

Suzanne Woolf <suzworldwide@gmail.com> Thu, 17 November 2016 04:34 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28760129593 for <homenet@ietfa.amsl.com>; Wed, 16 Nov 2016 20:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 9DxLdbGs1JBj for <homenet@ietfa.amsl.com>; Wed, 16 Nov 2016 20:34:34 -0800 (PST)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 20D54129484 for <homenet@ietf.org>; Wed, 16 Nov 2016 20:34:34 -0800 (PST)
Received: by mail-pg0-x233.google.com with SMTP id p66so87008456pga.2 for <homenet@ietf.org>; Wed, 16 Nov 2016 20:34:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bl03pRh4c5luny0XJjiT4ik/pdRlR4j78k5R3WnkATE=; b=VJkbdx4nb/KJs580x6kLTzbF9OJDWcISajkcWV+vqUasAopaGdetZdcNkmOje+NOkr aC0IoIM4McSxqXSmkQM1E0qB3bX93owrgdapKQMHut4kY+HXUZBc8kI/6xNAw0O0u9Xs 97aOJ/9ruyvwVQ0oo345kfsk6DbdBy0EXQiE/3+EnTD5Orf337PNcSoZSxnoCMk5e5td rmq84hGrPPBSgG1+CCO9YWPabcuMioMeKW6bkxtjyE1jemfLimUiwMcHaT4bKVmU2Mf3 n1Qh4Ixw0VpgJZF6Pp92bUcdV8vtG+I76HZ37CgQF8X3JzMrqzEPsmdx3oeM8klGwRM9 0rAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bl03pRh4c5luny0XJjiT4ik/pdRlR4j78k5R3WnkATE=; b=bgLAaWs+qUz/thafcVEFKZr8vvggLK2u6M/90+04oRoj35vmgAdV4C9PQPWcv6jyjG TxcVJmW4Il2MWJCCB8Lu4Ym788lHEL35aezcW9BY47JwKk+ILaxKPYr2xdj8Q3mb3v5A dsL6Pu1tHBGxdkGraj/0IGcvpQ5Ulwg3o2uz1CpdXWD49Qm7csEqQyPvCDI+riw+3cRJ pahPdksa1WUOTqYkuqGu4laBSe5s80jh8HvwJSYeUR/k4ftS/CL0zYEIWR4gOohwZfPB dk3GEF0Pcf21dEsoy+jkYp+lW1EE0UeYn4eBAfEnRw1XdgjCjo/dpgttJMaTveJxk5ev rcgA==
X-Gm-Message-State: ABUngve1iLYQz3YoCMj3wXoIY/JBHwyir/FCOZSlQBzz42rzFrg/z2CC1CRPn+m3O7JM8g==
X-Received: by 10.98.150.88 with SMTP id c85mr1890374pfe.68.1479357273454; Wed, 16 Nov 2016 20:34:33 -0800 (PST)
Received: from t2001067c03700144c5cff653a1873b37.hotel-wired.v6.meeting.ietf.org ([2001:67c:370:144:c5cf:f653:a187:3b37]) by smtp.gmail.com with ESMTPSA id b64sm1693154pfc.74.2016.11.16.20.34.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Nov 2016 20:34:32 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <20161116073452.D73AE5A47013@rock.dv.isc.org>
Date: Wed, 16 Nov 2016 23:34:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF33F759-5335-43FD-BAA6-4915FBD1064A@gmail.com>
References: <20161116054604.GB55057@mx2.yitter.info> <20161116063043.0CD6C5A467BC@rock.dv.isc.org> <CAPt1N1m_btPK8TGugoYd7iWxU6sEkPM288biBM3XSS7hRp25MQ@mail.gmail.com> <20161116072834.5E0695A46EC4@rock.dv.isc.org> <CAPt1N1=5KyXA7XLd3Ks6y+T+0SWSXcdXUTozbVw4ed3EwpQTYA@mail.gmail.com> <20161116073452.D73AE5A47013@rock.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/Ncsbv-dadPgqznD7T9EatOTG7Es>
Cc: HOMENET <homenet@ietf.org>, Ted Lemon <mellon@fugue.com>, Andrew Sullivan <ajs@anvilwalrusden.com>
Subject: Re: [homenet] On the TLD question and validatably-insecure delegation
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 04:34:37 -0000

Hi,

(no hats, just experience)

> On Nov 16, 2016, at 2:34 AM, Mark Andrews <marka@isc.org> wrote:
> 
> In message <CAPt1N1=5KyXA7XLd3Ks6y+T+0SWSXcdXUTozbVw4ed3EwpQTYA@mail.gmail.com>
> , Ted Lemon writes:
>> Well, yes, but it means that we need to ask ICANN to do an insecure
>> delegation, and there isn't a process for that.
> 
> We are adults.  They are adults.  We can talk together.  That should
> be all the process needed once there is consensus that the name and
> delegation are needed for protocol reasons.

Just for clarity: I have complete faith that this is true, but it’s important to appreciate the position ICANN may be put in if we ask the IANA to do an unsigned delegation in the root zone. This was Andrew’s initial point and it shouldn’t be lost:

* RFC 6761 creates a registry for special use domain names. There have been many fine arguments over a couple of years now in DNSOP about exactly what implications this registry has for the DNS and the usefulness of the domain name space generally, but from the process perspective, it’s an IETF registry, over which the IETF has policy authority to request an update. 

* the DNS root zone is a different registry, for which explicit policy authority lies outside of the IETF: not with IANA, or even ICANN-the-corporation, but with the naming community. 

The special use domain name registry created in RFC 6761 implies an expectation that the policy authority for the root zone will not take certain hypothetical future actions. But an update to it does not ask for a change to the DNS root zone registry.

If the IETF asks for an unsigned delegation in the root for a special use name, it’s requesting an update to the DNS root zone, for which neither ICANN nor IANA alone has the responsibility.

The practical implications of this, as Andrew noted, are unknown at this time— everyone who spoke in homenet yesterday about what ICANN could, should, or would do was speculating— but might very well include some level of need to consult the naming community. There are processes for that, but they take time and may not turn out the way we’d like.

I note again that this is not about what string is being requested, or about whether the IETF should consult ICANN about the special use names registry established in RFC 6761. It’s about a new process for requesting a new kind of change to the DNS root zone registry.

As I said at the mic yesterday: a second-level name under .arpa avoids this registry authority problem altogether. I understand the concern that the resulting names are ugly, but the policy authority over .arpa is held by the IETF community, via the IAB. The process of asking the IAB for an unsigned delegation in .arpa is defined already, and is likely to be vastly simpler and faster than any such process for requesting an unsigned delegation in the root zone.


Suzanne

> 
>> On Wed, Nov 16, 2016 at 4:28 PM, Mark Andrews <marka@isc.org> wrote:
>>> 
>>> In message <CAPt1N1m_btPK8TGugoYd7iWxU6sEkPM288biBM3XSS7hRp25MQ@mail.gmail.
>> com>
>>> , Ted Lemon writes:
>>>> Yeah, this sunk in for all of us when we were standing around outside
>>>> the meeting room kvetching.   It's a bit of a conundrum.
>>> 
>>> No.
>>> 
>>> All it means is that there isn't policy for this which is exactly
>>> the correct state of affairs for special names in the root namespace.
>>> Each name needs to be individually handled as each is special with
>>> its own requirements.
>>> 
>>> Mark
>>> 
>>>> On Wed, Nov 16, 2016 at 3:30 PM, Mark Andrews <marka@isc.org> wrote:
>>>>> 
>>>>> In message <20161116054604.GB55057@mx2.yitter.info>, Andrew Sullivan wri
>> tes
>>>> :
>>>>>> Hi,
>>>>>> 
>>>>>> Mark Andrews's point about a DNSSEC insecure delegation today was not
>>>>>> I think fully appreciated.
>>>>>> 
>>>>>> In order to create a top-most label in the domain name that can be
>>>>>> used this way and that has the necessary properties, we cannot simply
>>>>>> instruct IANA to do it.  That is in fact creating a delegation in the
>>>>>> root zone of the DNS.  I believe that RFC 2860 (the MoU between the
>>>>>> IETF and ICANN) does allow us to create special-use domain names at
>>>>>> the top-most level.  But I do not believe it allows us to create
>>>>>> special-use domain names at the top-most level _in the DNS_, because
>>>>>> that is control of the root zone and it is unambiguously the province
>>>>>> of ICANN.
>>>>>> 
>>>>>> Therefore, if the WG decides to use a top-level label for these
>>>>>> purposes, we have to apply to ICANN to get it delegated from the root
>>>>>> in a provably insecure fashion.  Interestingly, ICANN actually has a
>>>>>> policy that it won't delegate things from the root any more that are
>>>>>> _not_ DNSSEC signed, and the whole point here is in fact to add an
>>>>>> entry that is contrary to that policy, so getting such a delegation
>>>>>> would require ICANN to change its policies before it could happen.
>>>>> 
>>>>> I suspect this is a mischaracterization of the policy.  GTLD
>>>>> delegations are so constrained.  This is not a GTLD delegation.
>>>>> 
>>>>> New country code delegations are not so constrained.
>>>>> 
>>>>> We are not asking them to delegate away from the roots.
>>>>> 
>>>>> root zone:
>>>>> HOMENET. NS A.ROOT-SERVERS.NET.
>>>>> ...
>>>>> HOMENET. NS M.ROOT-SERVERS.NET.
>>>>> 
>>>>> homenet zone:
>>>>> HOMENET. SOA a.root-servers.net. nstld.verisign-grs.com. 1 1800 900 6048
>> 00
>>>> 86400
>>>>> HOMENET. NS A.ROOT-SERVERS.NET.
>>>>> ...
>>>>> HOMENET. NS M.ROOT-SERVERS.NET.
>>>>> 
>>>>> B.T.W. this should also be done for .ONION and .LOCAL if we want
>>>>> local DNS resolvers to intercept these queries.  DNSSEC keeps
>>>>> getting forgotten.  The only reason people aren't screaming
>>>>> is that there are very few validating clients and the both
>>>>> .ONION and .LOCAL don't use the DNS.  SERVFAIL is nearly as
>>>>> good as NXDOMAIN for these use cases.
>>>>> 
>>>>> HOMENET uses the DNS.  If one can get a trust anchor for HOMENET
>>>>> installed in every validator there shouldn't be any queries for
>>>>> HOMENET/DS.
>>>>> 
>>>>>> That is an important practical fact that ought to be taken into
>>>>>> consideration when deciding what kind of label to use.
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> A
>>>>>> 
>>>>>> --
>>>>>> Andrew Sullivan
>>>>>> ajs@anvilwalrusden.com
>>>>>> 
>>>>>> _______________________________________________
>>>>>> homenet mailing list
>>>>>> homenet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>> --
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>>>>> 
>>>>> _______________________________________________
>>>>> homenet mailing list
>>>>> homenet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/homenet
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet