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

Ralph Droms <rdroms.ietf@gmail.com> Wed, 01 February 2017 20:50 UTC

Return-Path: <rdroms.ietf@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 1FB8F129431 for <dnsop@ietfa.amsl.com>; Wed, 1 Feb 2017 12:50:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 DHibvKSX-h5e for <dnsop@ietfa.amsl.com>; Wed, 1 Feb 2017 12:50:35 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 A342F129550 for <dnsop@ietf.org>; Wed, 1 Feb 2017 12:50:35 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id v23so285031538qtb.0 for <dnsop@ietf.org>; Wed, 01 Feb 2017 12:50:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Jai3gHNGCCwwvmFOiwn2EuJE2vyYcmzrBKa8Uc2KdNQ=; b=PPugQMBKA6jXy5sSNJs5KsbGQjNuxaxZwIKEQkKVyp7WViuTKrroFkgiepyGeVqfV0 tt6Qf8zAuozSUYhHw9J/bYoE4MZI7ZY2qRO9iWL77yYZfFM2qO4ZjijBKvg/333W3dTy xYTYGXi+s7dlFYve//eGKZVHxCfdeYwriT+JxVsxZl2ibX6S2XXzeH7im8GCcERHCA1S Prr+qn0zS9DKVeZmWRjhXzKj7wNOMh9hmZgm37ppYHm5JOlNbS5gyfijQrfCHU6pvKTP WwZaqqwPxxgo9PWerESMnHZOMTrxNI8r7n5cGb8PaQsLPnX80zORoDNR0Dxvh3/1BbNw ryNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Jai3gHNGCCwwvmFOiwn2EuJE2vyYcmzrBKa8Uc2KdNQ=; b=aiuD+nqgL/FegTRqmnYuPDByMnIk4okiScV4VR7IG80MPBLyo6aR454kJaWhUGpY0e c55tn3Rg4KzJPV4j+rvjZMZFFGWNflVXkH40WNC8c+ezho5wXTw4WoN78lGBq1sfeqwt PvmpnObVjsZ6S3r96TpCgUokPLCZiklbB1vgeuMk5FsMCwff5zs7XYLL6PeuDHGQVWqV ZWH4whZqmB1PA7orOXLMYmsSOLCMRIVUnispWjif8dyfcpCBBNpgn+bSoitipeUyDEBw Wy/xUnLqCbbexu25851nHF/uRzaDaUfRzsfWxaxdXzZGlb4GY0GGl0ThL+38YtsInSG8 9LZw==
X-Gm-Message-State: AMke39k5qI4a2Y3/aUN3y1v7kdAQoq4HZSRNThSX2ck60HrSClYy1OjFxaazP/M4Xsz4Hw==
X-Received: by 10.55.81.136 with SMTP id f130mr4860140qkb.75.1485982234675; Wed, 01 Feb 2017 12:50:34 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:4ca6:5062:1722:a062? ([2601:18f:801:600:4ca6:5062:1722:a062]) by smtp.gmail.com with ESMTPSA id h40sm19639083qtb.6.2017.02.01.12.50.34 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 12:50:34 -0800 (PST)
From: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DFE7A880-CB61-4BA2-A686-B5F8093FB8B8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 01 Feb 2017 15:50:32 -0500
References: <CAHw9_i+8PA3FQx8FqW-xQ_96it7k-g5UrMB7fxARUi1gwQ++hw@mail.gmail.com> <CA+nkc8AhLe7nbPRkGixi93SGNZQhw+TACUDa8=pGsWM5YHJE0w@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <CA+nkc8AhLe7nbPRkGixi93SGNZQhw+TACUDa8=pGsWM5YHJE0w@mail.gmail.com>
Message-Id: <C75FC005-ED38-436B-A93E-C2D2B7CDDE9C@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cvkS1Gv2ilJhm1hYnJDcRbMzKL8>
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: Wed, 01 Feb 2017 20:50:41 -0000

> On Feb 1, 2017, at 3:47 PM, Bob Harold <rharolde@umich.edu> wrote:
> 
> 
> On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari <warren@kumari.net <mailto:warren@kumari.net>> wrote:
> Hi there all,
> 
> I have just posted a new version of alt-tld, which folds in a number
> of suggestions and comments from various people -- thank you for
> those. As the document was parked I held off making some of the larger
> edits; if you sent comments and I missed them, I apologize - please
> send them again (or point at them) and I'll try address them.
> 
> 
> The largest outstanding issue is what to do about DNSSEC -- this is
> (potentially) a problem for any / all 6761 type names.
> The root is signed, so if a query leaks into the DNS (as they will),
> an (unaware) validating resolver will try resolve it, and will expect
> either a signed answer, or proof of an insecure delegation; without
> this things will look bogus, and so resolvers will SERVFAIL.
> 
> Clearly, a signed answer isn't feasible, so that leaves 2 options - 1:
> simply note that validation will fail, and that SERVFAIL will be
> returned in many case (to me this seems "correct"), 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.
> 
> This is a fine thing to request in an IANA consideratons, but isn't
> necessarily *useful* -- the IANA has the technical ability to add
> stuff to the root zone, but not the mandate (this is like walking into
> a bank and requesting the teller gives you a bunch of money - they may
> be able to do so, but aren't actually allowed to.. :-)).
> 
> Some people have suggested "Well, we (or the IAB) can just ask ICANN
> politely to do add this, they are in charge of the DNS root, they'll
> help out, no worries...."
> Unfortunately, this is only partly accurate -- adding an (insecure)
> delegation to the root would make .alt be a "real" TLD. ICANN is just
> an organization, they are driven by a multistakeholder[0] process, and
> there is a huge amount of process and similar around creating a new
> TLD -- go read the 300+ page gTLD Applicant Guidebook (Version
> 2012-06-04 ) for a fun taste of this.
> This would likely require convincing "the naming community" that, for
> some reason the IETF is special and should get a "free"[1] TLD, and
> that it is exempt from, well, basically all of the existing
> requirements.....
> 
> I'd started putting some strawman text into the draft[2], so that we
> could have something concrete to discuss and poke holes in, but ripped
> it out because it was clearly not going to fly / pure fiction...
> 
> So, what do we want to do here? This is a WG document, the authors
> will (of course) do whatever the WG wants, but my personal view is
> that asking for an insecure delegation, while technically superior, is
> simply not realistic.
> 
> This discussion is somewhat about .alt, but other special use names
> will likely have the same issues and concerns, and so we should
> consider this in the larger context.
> 
> For example, homenet already has had some of this discussion -- see:
> https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation <https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation>
> 
> 
> W
> [0]: By law, all mentions of ICANN require the use of the word
> "mutistakeholder"....Hey, this is no more crazy than some of the other
> new rules....
> 
> [1]: Yeah, 'tis not a useable TLD in that you cannot sell names and
> have them work in the DNS, but this is fairly subtle...
> 
> [2]:
> ------------------
> [ Editor note: This section is a strawman (and so is more
> conversational than expected for the final version) -- it is likely to
> change significantly, or more likely, be removed entirely. ]
> 
> The point of adding this entry to the "Special-Use Domain Name"
> registry is to create a namespace which can be used for alternate
> resolution contexts, and which will not collide with entries in the
> IANA DNS root.
> 
> Unfortunately, queries will still leak into the DNS, and, as the DNS
> root zone is signed, validating resolvers which are unaware of .alt
> will attempt to DNSSEC validate responses. If there is not an insecure
> delgation for .alt, DNSSEC validation will fail, and validating
> resolvers will return SERVFAIL, causing additional lookups or other
> unexpected behavior.
> 
> In order to avoid this, the IANA is requested to add an insecure
> delegation to the root-zone, delegating .alt to AS112 nameservers (or
> to an empty zone on hosted by the root).
> ------------------
> 
> 
> It appears to me that requesting an insecure delegation is the right thing to do, as a "technical use".  We have, so far, been very careful in what we ask for.  If ICANN does not agree, then we can discuss other options.

I agree.

- Ralph

> 
> -- 
> Bob Harold
>  
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop