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

Ted Lemon <mellon@fugue.com> Wed, 14 December 2016 17:45 UTC

Return-Path: <mellon@fugue.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 AAED91299AA for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2016 09:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 0NA7msE5qp3o for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2016 09:45:46 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 06D311299A3 for <dnsop@ietf.org>; Wed, 14 Dec 2016 09:45:46 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id q130so29416060qke.1 for <dnsop@ietf.org>; Wed, 14 Dec 2016 09:45:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XJGWFK1vN+rkmZTfhWMkZhZNwHIqpMD8Po0ynKi5pWU=; b=eR4FK+yMupl0QU7z3nGxfVkpz1M+bHtVZzfiz/IYaIjR1hBorkqaiFqMMyKJB4XU9e Zj+oANacyQKLKrfm4SQ2MIePqo08PHIYxfYoQ507xZKYuTAmmhrv2CKp6nhmlQffm13P 1uA28wMPTXWxZ+ol376SFi5Qu9By5VY8NPihuIki8h5cGMhwqekJhoQkMzlRZvddOdFc FcEFSOaO/uq3qh1Nt7MyDsrXRbslilrwxLTaQihdEgduGIpdrWSmwsc/3DDmCq3BHf8V l+QGw3NKZyKcMgG96vRqX0DpTYqzZ+hhqT9TGJurN12HmjCGzyP+TjESLPHGgZpVWHUj gNBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XJGWFK1vN+rkmZTfhWMkZhZNwHIqpMD8Po0ynKi5pWU=; b=DLCqpwrp5K19WecyXfIxE62znHTgHlYPBe3LOw3piU4425op2plZEe6rrb6w6ibaXn 6YRY3R2cptEzex36RT92mOiqSXRGDdwHtnua7m6eaFryYaCvFgIUO4jE5+WW6Vic5pj9 txx5dUnye/6IQWXFx2lcm69uJEGd4GVGMBFb3163dVJDvPSQgF35xSvkYRpwndQGnxOX /wcij7E2DpzXP7SXXu0YxJGhrrLwjeor+YPAjf6rRaQuyoQDOqdVp1j8QkNiCo/xiHMw /kMk0Z7oAYYbTYFVrHeV4nj1PQesT9zC+j5pqnAthQ1uQw5XsPtEL+s3oaUMaXgWFoAG Cgwg==
X-Gm-Message-State: AKaTC00wKsvfDdytnQe5BYx50ssiC6GlsKqB4rj/yxNF+pI0+VJxAvu6rXiqSq0ZEb6NWg==
X-Received: by 10.55.115.6 with SMTP id o6mr97082011qkc.271.1481737543625; Wed, 14 Dec 2016 09:45:43 -0800 (PST)
Received: from [192.168.1.131] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u7sm21538883qkh.2.2016.12.14.09.45.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 09:45:42 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <807A9F78-329B-4336-A071-66DB286E27D6@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_393D7325-D15E-4FAC-8691-2FFFA702C2E2"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Wed, 14 Dec 2016 12:45:40 -0500
In-Reply-To: <809B3342-EB5C-4A25-B01E-D76A243FD295@shinkuro.com>
To: Steve Crocker <steve@shinkuro.com>
References: <4ab2a538-603e-4e7a-3be9-ad75ed459006@bellis.me.uk> <E773C5B4-BA00-488C-9854-C729B671DFBD@gmail.com> <95E95A61-2079-498B-91C6-E98B50B84044@shinkuro.com> <CAPt1N1nCWgEtsMY4s669CHicWppyz9wCVYA9HR0QR_rGOPXSfA@mail.gmail.com> <CE36578B-780B-4222-B5A8-F6A252259234@shinkuro.com> <CAPt1N1n+PcuJ+AU-6U4TFiJvjNWz1PRNNp+y=zbnMSxZVKZ57A@mail.gmail.com> <809B3342-EB5C-4A25-B01E-D76A243FD295@shinkuro.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eQ6oQjHr95HUS4FKWCGZyycPPm8>
Cc: joel jaeggli <joelja@bogus.com>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>, Terry Manderson <terry.manderson@icann.org>
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: Wed, 14 Dec 2016 17:45:47 -0000

On Dec 14, 2016, at 12:21 PM, Steve Crocker <steve@shinkuro.com> wrote:
> If it doesn’t have a globally unique meaning, it doesn’t make sense to query the root for an answer.
> 
> What problem is trying to be solved?  I suspect whatever the problem actually is, the answer will be something other than adding an unsecured delegation to the root zone.

When considering problems, it is better to consider the problem first, rather than proposing solutions first. :)

The problem is that we (the working group) want DNSSEC validation to be as broadly enabled as makes sense.   In my opinion, this means that hosts should be doing DNSSEC validation.   However, the expectation is that they will be talking to their local caching resolver to get the information they need to do validation.   What we want is for the local resolver to be able to present a consistent picture of the homenet domain that is locally consistent and will not fail validation.   We do not want to have to specially configure resolvers—it’s not reasonable to expect end users to do this, and I don’t want to open up a security hole by setting up a way to do it automatically.   What we want is for validation on the homenet to Just Work.

We can of course in theory design a secure extension that allows DNSSEC validation to work on homenets through automatic configuration of trust anchors, but we can’t assume that all resolvers will support this functionality.   Resolution on the homenet has to work even if we are using a validator that doesn’t support special handling of trust anchors for .homenet.   And, frankly, we don’t know if we can come up with a secure way to do trust anchors on homenets even for hosts that decide to support them.   I want to think we can, but we can’t assume that we can.

So while in theory, not querying the root server would be a way to address this, not querying the root server indirectly through the cache is not an option, because we have to provide valid data from the root about .homenet.   If that valid data is a secure denial of existence for .homenet, then no name in .homenet can possibly validate.