Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

Michael StJohns <msj@nthpermutation.com> Thu, 15 December 2016 21:41 UTC

Return-Path: <msj@nthpermutation.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 04499129482 for <dnsop@ietfa.amsl.com>; Thu, 15 Dec 2016 13:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 x-kiFdkgaMKZ for <dnsop@ietfa.amsl.com>; Thu, 15 Dec 2016 13:41:16 -0800 (PST)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 02D361293D6 for <dnsop@ietf.org>; Thu, 15 Dec 2016 13:41:16 -0800 (PST)
Received: by mail-qk0-x242.google.com with SMTP id t184so479958qkd.1 for <dnsop@ietf.org>; Thu, 15 Dec 2016 13:41:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=prMnBq5dZhbeNqmKhJCjnRiS5nOMu120CmXRKVr6H2M=; b=W+9LXqgfeFPaRswYBOuTvIqz7xaxnGCEKLLuy1K0ec6mPthlGTNcFMDwDkQAslZRh4 WZltUXZdfXfEVyWjIwVik5gkYSdfyrnzsWLXE3E/srCS7rkDPUo54XbVPLINjBdBXaEB CvKiGpCuDxeaRDA+HN/dXUo5InQjPd/Qn/cFB8dx/g1tE4WW8oHrAiSkJRMnD+w1koat 63/pzNhJZhIqJ93yh7BQG/bb1OTpd1L9swaFE6CUX5T+rGASF6yRzUJfTmWvhtN0qBpI DWVDCb6bGhKQe09EkH87XrHGHVtXAIHcxFBL6Eb/dIN+iDMO6onUZb/rLEcwpLHhfTC0 76Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=prMnBq5dZhbeNqmKhJCjnRiS5nOMu120CmXRKVr6H2M=; b=dehuKDM+1CLhtR4axNX3GJOzFNhWZoxZGJn/gfEphC+IhOyUxgistUrkgIdK8g0rej Cng2Pp0T+hodlf+SuhyXWxfIlQK828QOWtq5nFnAZnAkB33+GqyInWwH3mNr2vtKFcQ9 ldwTos/1fGk07q73UjvqNNK/tXXYvGcKaMbc4uJRWgLrw5DZa9EnTMlU7pMTi0P3orHp kMamRoHB8zBkJUsFTKDQdR/Qbl5vJqZL3uCLs2EgB9LLgwePW5wj/M2wVU3iXtu4DlRH YbiEQcmR1T5MrgCqlPiorJ3TgZXj6UiigKnhUiL1K6RCVQAgycEO4Rt0UyD/QLKz43et yUNg==
X-Gm-Message-State: AIkVDXKpH75Vm8TfsUI7ESHRzzEzDfMSa/g2GPz86a9fE/WgKTnxqbRHWGQUJ+W0TL/NTg==
X-Received: by 10.55.42.197 with SMTP id q66mr2780908qkq.198.1481838074507; Thu, 15 Dec 2016 13:41:14 -0800 (PST)
Received: from ?IPv6:2601:152:4400:9b5f:609b:144f:cb12:1626? ([2601:152:4400:9b5f:609b:144f:cb12:1626]) by smtp.gmail.com with ESMTPSA id c76sm2119719qke.0.2016.12.15.13.41.12 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Dec 2016 13:41:13 -0800 (PST)
To: dnsop@ietf.org
References: <4ab2a538-603e-4e7a-3be9-ad75ed459006@bellis.me.uk> <B192A1B3-03FF-43D1-AD30-12BBA2D65DF0@gmail.com> <9fe0e34d-51e9-bdf3-a650-d8b3681f1cd8@bellis.me.uk> <CAPt1N1=Z2xERw68-=iFGgYYnEO3eDW-8tvhmTmaf4+vU-24grQ@mail.gmail.com> <C059877D829F76429F49E0B48705D888F7FD2C7B@EXCH-01.CORP.CIRA.CA> <4A870505-070B-4065-B360-5A98485E4CEB@fugue.com> <313759CF-B72F-401D-BA26-79C214C30686@shinkuro.com> <8D7E8E5C-EC8E-46E9-9C07-947D7A7F69E3@fugue.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <61ebc3c3-557a-1be8-7205-648e1e83411c@nthpermutation.com>
Date: Thu, 15 Dec 2016 16:41:15 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <8D7E8E5C-EC8E-46E9-9C07-947D7A7F69E3@fugue.com>
Content-Type: multipart/alternative; boundary="------------C9CA5A0002ADC5B9E1C47FEB"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vlWF-m4pgxcoqOei5rMp5SW1wSk>
Subject: Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"
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: Thu, 15 Dec 2016 21:41:18 -0000

On 12/15/2016 3:11 PM, Ted Lemon wrote:
> On Dec 15, 2016, at 2:23 PM, Steve Crocker<steve@shinkuro.com>  wrote:
>> I don’t understand what is meant by an “unsecured delegation.”  I also don’t understand what sort of delegation you want, irrespective of whether DNSSEC is involved.
> There would be a delegation for .homenet in the secure root, which would point at the AS112 servers, and would have no DS records.
>

For clarity, the difference between unsecured and secured  (or as 
4033/34 call it unsigned and signed) is the presence of the DS record in 
the parent.

The problem with providing an unsecured delegation for .homenet is that 
items subsidiary to .homenet become spoofable in the wider internet and 
that's not necessarily a good thing.  It might make life easier for the 
homenet folks to use the unsecured .homenet local zone, but it might 
have adverse consequences for the non-homenet folken.

RFC6840, section 5.10 talks about how to handle nested trust anchors (in 
this case consider the global "." trust anchors and one or more local 
".homenet" trust anchors).  If ICANN does a secure delegation to a DS 
record, any 
non-homenet-compliant--but-dnssec-validating-with-root-trust-anchors end 
point or resolver will not see the .homenet zone.  In other words, you 
force a fail-secure for those systems that don't implement the Homnet 
structure.  In the Homenet-compliant case, you generate a local trust 
anchor, install it in the various machines and configure your resolution 
to use the "Accept Any Success" policy.

So the question:  fail-secure-bogus or fail-unsecured (spoofable) with 
respect to resolving .homenet on non-Homenet systems?  I'd vote for 
fail-secure and a secured/signed delegation.

I also think "secured but bogus DS records" is probably going to be a 
more acceptable use pattern for the long term for special use names - if 
for no other reason that to give us some control over the swamps.

Mike

ps - I see that at least the framework for .homenet local trust anchors 
was done: 
https://datatracker.ietf.org/doc/draft-mglt-homenet-dnssec-validator-dhc-options/