Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
Paul Wouters <paul@nohats.ca> Sun, 21 February 2021 22:28 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 D04A93A1266 for <dnsop@ietfa.amsl.com>; Sun, 21 Feb 2021 14:28:33 -0800 (PST)
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 LiqctvA_-Gqz for <dnsop@ietfa.amsl.com>; Sun, 21 Feb 2021 14:28:29 -0800 (PST)
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 4145A3A1264 for <dnsop@ietf.org>; Sun, 21 Feb 2021 14:28:28 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DkKhp4Xvwz38Y; Sun, 21 Feb 2021 23:28:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1613946506; bh=LjblEmx7wOEJ8uLVNORyizIY/O1C2m/a42FkAlq+l0I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tiGGCZL38YDKzD0q9tTD8DtLK4Qx7aQIceoJAs6ZzARTMyKuzBVrR5eQZJ7HoBM9U aCmhrc3GyX9qa+jhtP0dD0rDrgnIIXHTiRFdnT+lKswI5B8hRWfIpDE/vjy3qWU4nw 18scnDDN8Im6yUFfkkKzzPp/fjwpzu4KtkfdgCqE=
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 YxUvWY5PwRyQ; Sun, 21 Feb 2021 23:28:25 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [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; Sun, 21 Feb 2021 23:28:25 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B04616029B62; Sun, 21 Feb 2021 17:28:23 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A7A8566B1E; Sun, 21 Feb 2021 17:28:23 -0500 (EST)
Date: Sun, 21 Feb 2021 17:28:23 -0500
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: <D3EF7294-2A22-4D01-A886-3061998887AF@hopcount.ca>
Message-ID: <d17c1b89-3f7-9a4e-619d-936b202b2b@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> <alpine.LRH.2.23.451.2007301639420.418549@bofh.nohats.ca> <D3EF7294-2A22-4D01-A886-3061998887AF@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VHqLvN0PARjcBvAFKFK5fRwsLDE>
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: Sun, 21 Feb 2021 22:28:34 -0000
On Thu, 30 Jul 2020, Joe Abley wrote: >> 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. > > Can you provide some information about that? I think it would be helpful to understand the problem that people are bothered by. The amount of times people quote Thomas Ptacek's article on this issue is really high. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ It doesn't matter how much we debunk it and say this is an enigma problem, or that ICANN or rootservers can be trusted and it is just a conspiracy theory. We can eliminate this entire discussion by setting 1 bit. It's easy and cheap to do. And it signals good intensions by TLDs and ICANN/Root for transparency in general. And might even prevent some governments from cooercing TLDs because well, they won't be able to anymore. >> 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. > > Well, I didn't say that we can never afford to deploy anything. Clearly we can deploy lots of things all the time. I think I've explained why we couldn't just turn this on in ORG right now, and so a requirement to do so would be a problem. This is quote the more nuanced phrasing you use now. Now you are saying that yes, with some changes to your infrastructure, you can support this. Where as before you said "we can never ever support this". I think that is good to have clarified. > The lines of code to be added to particular implementations are not the only measure of complexity in deployment, however. We don't have a good handle on all the software that exists between application and authority server, nor how it interacts. There are costs in resolution failures that appear intermittent because they happen with some applications, networks or hosts but not others, assuming that it is deployed anywhere. I don't understand this. Let's say example.org has: example.org. IN NS ns1.deleted-domain.org. ns1.deleted-domain.org. IN A a.b.c.d Currently, .org would serve the 'glue' A record that it would sign. with the .org ZSK. You create a new zone, broken-nameservers.org, and you change the above to: example.org IN NS ns1.deleted-domain.org.broken-nameservers.org. ns1.deleted-domain.org.broken-nameservers.org. IN A a.b.c.d You run and sign broken-nameservers.org. without the DELEGATION_ONLY flag. The existing broken glue keeps working. And you even gain a new indicator and could inform people on www.broken-nameservers.org that their domain is in purgatory and they better start fixing it. And now you can run your .org as DELEGATION_ONLY zone. > If the technical difficulties for particular registries like ORG can be circumvented but the benefits are not obviously compelling, then there's the question of why any commercial registry would implement this proposal. If it needs to happen as a contractual obligation, then that means contract changes and although that's very much not my area, my sense is that that's a fairly heavy ball that needs to be rolled up a steep and tall hill. That sounds like a cost to me. > > Without widespread implementation, I'm not sure how the problems (admittedly, problems that I don't really understand) will actually be addressed. The costs will remain, however. And right now I haven't heard a single example of a TLD that might be in a position to implement this (not saying there isn't one, just that I haven't heard an example). I think this argument is the same as for IPv6, DNSSEC, and many other new protocols. It's like saying there is no reason to add signaling to wifi hotspots because no one will implement it because they have some interception method that works now. Still, we are trying to improve the protocols there too so we can at some point in the future enhance and improve those protocols. Maybe for .org that will only be after the market pressure that you explained you feared earlier in this discussion. To me, that would be a success of IETF increasing the trust in DNSSEC - even if we ourselves believe root servers or TLD servers would never be coerced into a position of provding maliciously signed data to third parties. Paul
- [DNSOP] Questions on draft-ietf-dnsop-delegation-… Ben Schwartz
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Petr Špaček
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Ben Schwartz
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… John Levine
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Brian Dickson
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Patrick Mevzek
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Patrick Mevzek
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Ben Schwartz
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Tony Finch
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… John R Levine
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Brian Dickson
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… John Levine
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Hugo Salgado
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Patrick Mevzek
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… John Levine
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Joe Abley
- Re: [DNSOP] draft-ietf-dnsop-delegation-only is s… John Levine
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Paul Wouters
- Re: [DNSOP] Questions on draft-ietf-dnsop-delegat… Ben Schwartz
- Re: [DNSOP] draft-ietf-dnsop-delegation-only is s… Viktor Dukhovni
- Re: [DNSOP] draft-ietf-dnsop-delegation-only is s… Paul Wouters
- Re: [DNSOP] draft-ietf-dnsop-delegation-only is s… Joe Abley
- Re: [DNSOP] draft-ietf-dnsop-delegation-only is s… John Levine
- Re: [DNSOP] draft-ietf-dnsop-delegation-only is s… Paul Wouters
- Re: [DNSOP] draft-ietf-dnsop-delegation-only is s… John R Levine