Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Paul Wouters <paul@nohats.ca> Thu, 30 July 2020 21:10 UTC

Return-Path: <paul@nohats.ca>
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 E642A3A0CCF for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 14:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 e4coqxPX713g for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 14:10:35 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3383A0CCB for <dnsop@ietf.org>; Thu, 30 Jul 2020 14:10:34 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BHjk10NdVz9Y8; Thu, 30 Jul 2020 23:10:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1596143433; bh=jNNm7Mu6bG1TjayCT29noyrKi4zXvWbUjRpZTfcYObg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=BCzMwz4cryMaMxOm/XC4pVpD4Gyo9JwQp4ifMjtHk12irFn9kpLGTwnpT52NtX4LM 1y/xQtRUpYLudBWahAr3i1jmaQkjsylNy9GQVo4KjKARb2J0AyqkFVP+Q8GgqowgTI IT1oLma40DtCX18J/E3kP3X0q/2APimao3ol8nzw=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2wK8bgK83sDZ; Thu, 30 Jul 2020 23:10:31 +0200 (CEST)
Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 30 Jul 2020 23:10:31 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8FC426029BA4; Thu, 30 Jul 2020 17:10:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 878B6669F1; Thu, 30 Jul 2020 17:10:30 -0400 (EDT)
Date: Thu, 30 Jul 2020 17:10:30 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Joe Abley <jabley@hopcount.ca>
cc: Ben Schwartz <bemasc@google.com>, dnsop <dnsop@ietf.org>
In-Reply-To: <5F8A7305-44B0-40A3-9639-B194A928168B@hopcount.ca>
Message-ID: <alpine.LRH.2.23.451.2007301639420.418549@bofh.nohats.ca>
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca> <CAHbrMsDoYO_hsuCjLeg9pwut_dB703uJ6tgGV0NDq_5sSUWJwA@mail.gmail.com> <alpine.LRH.2.23.451.2007301546120.418549@bofh.nohats.ca> <5F8A7305-44B0-40A3-9639-B194A928168B@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/a9n5N0sV2MjUlvc42SEWn_4pTCI>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Jul 2020 21:10:37 -0000

On Thu, 30 Jul 2020, Joe Abley wrote:

> My sense is that this is a nice idea in theory but doesn't solve a problem that anybody actually has, and the camel is starting to look a little bit fraught. But I don't think any proposal should succeed or fail based on anybody's uninformed sense, hence the request for more data.

This proposal is meant to increase the amount of trust people can place in
DNSSEC by decreasing the hard trust that is currently required of ICANN,
Verisign and the TLD operators. I understand in our community, we do
not see this as a big problem. Unfortunately outside our community it is.

It is further interesting that you raise your point of "the risk analysis
shows we can never afford to deploy this" when a few months ago you
raised the reverse point that "we dont want to be forced to have to use
this to be seen trustworthy". Both arguments cannot be true.

As for the DNS camel, we are talking about 1 bit and many 20 lines of
code in the resolver. Looking at the rest of the current drafts in
DNSOP, I think this isn't going to break the camel's back.

As for your single issue, the glue issue, you could also change your take
down system.  You could bring up a take-downXXX.org. zone and update
the NS glue for the GOODDOMAINS.org to use that, give out the original
IP and sign it with take-downXXX.org's key. It would even work with
resolvers that insist on hardening and confirming glue, so you would
actually improve your .org deployment independently of this draft.

What I'm trying to avoid is adding complexity to support this already
unstable "run on glue" domains. Sure, we could add an exception for
A/AAAA since these records are of low value to protect because onpath
attacks can just NAT/route it to them anyway, but doing so would
actually increase the complexity of the code and muddle the expectation
of the protetion of "delegation only" zone.

Paul