Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
Paul Wouters <paul@nohats.ca> Sun, 21 February 2021 22:01 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 EB0BF3A121E for <dnsop@ietfa.amsl.com>; Sun, 21 Feb 2021 14:01:47 -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=unavailable 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 QSoh6wWB5ro6 for <dnsop@ietfa.amsl.com>; Sun, 21 Feb 2021 14:01:46 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 D3B2D3A1219 for <dnsop@ietf.org>; Sun, 21 Feb 2021 14:01:44 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DkK5y1ZPPz388; Sun, 21 Feb 2021 23:01:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1613944902; bh=yqZQlTS8X9oGUslNxb/olfzr5Ln28+aZ4d/NmynriD8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Fc/jqg2w+NAp1BLps21lN2UXWSon/1fHW+j2wqolmRtJJiyQnZQCZL1pwcGzQJPTi evedEjBER/jCW7vu29uVDMe5WRwuBBffKQvh4Wx/n7r+Frxsy8os+NLfZ0w+LzXrqV E15HRjHYvRQ7d2mx3igZRmZP/XA4aUm63HawmyHA=
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 3P4rheLnOgwT; Sun, 21 Feb 2021 23:01:40 +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:01:40 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1E9AC6029B62; Sun, 21 Feb 2021 17:01:39 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 15F3166B1E; Sun, 21 Feb 2021 17:01:39 -0500 (EST)
Date: Sun, 21 Feb 2021 17:01:39 -0500
From: Paul Wouters <paul@nohats.ca>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com>
Message-ID: <733b311-c6b8-c3eb-10e-5a3459836f@nohats.ca>
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fORatp6g5rIeZWVTZL-mBnR7keA>
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:01:48 -0000
On Wed, 29 Jul 2020, Ben Schwartz wrote: > I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to make sure that the draft isn't overstating the achievable benefits. To that end, I have some > questions about the text of the -01 draft. > > (I recognize that these are issues I've raised before, but I still haven't gotten answers that I understand.) > > Assuming the claims are correct, I think they need some clarifications for naive readers like myself (and possibly deduplication, since some claims are repeated in > different sections). > > > Exposing such targeted attacks requires a transparency audit > > infrastructure similar to what is deployed for PKIX ([RFC6962]). > > However, a DNSSEC version would need to log significantly more data, > > as all signed DNS data used by a DNSKEY must be recorded in order to > > prove that data signed by a parent zone's DNSKEY was out of expected > > policy. The very distributed nature of the DNS combined with the > > typically frequent zone resigning rate makes such transparency logs > > prohibitively expensive and nearly impossible to operate. > > How does this draft alter that cost? For delegation-only zones that are in compliance, it seems like the cost is not changed. Whether or not they are in compliance does not alter the cost. Once the delegation-only bit it set, only the DS/DNSKEY records need to be logged instead of all data signed with the parental key. Any "deep signed" data by the parental key will be rejected automatically by resolvers supporting this, so there is no requirement to log these. It might be that the occurance of this deep signed data is rare, but without the delegation-only flag, you cannot determine if such deep signed data is legitimate or not. That is what the delegation-only flag indicates. > Presumably violations will be rare, so they won't contribute significantly to the cost. I don't know how rare this is, but for example if it became known that this logging was happening (due to not having delegation-only) then atttackers could spam the DNS transparency log with deep signed data that would have to be logged. Attackers could also try to hide and seek via CNAMEs. All of these would need to get logged. Versus only logging DS/DNSKEY. > > Additionally, it would require zone owners to expose all their zone > > data to any public log operators, thereby introducing privacy > > implications and exposing all relevant DNS data to a public archive. > > I don't understand how this flag would alter that exposure. If my zone is already delegation-only, how does adding this flag improve privacy? I have removed this section, as with our current DNS model, all queries are seen anyway by some people (like Paul Vixie et all) > > At the time of this writing, the list of entries in the > > public suffix list contains over 8800 entries as well, with 73 wild- > > card entries (prefixed with a "*") indicating that all of their > > (unknown number of) children are public registration points. In the > > absence of an interoperable mechanism (like this draft provides), it > > is infeasible that a validating resolver or auditing log could know > > which of these zones are delegation-only without individual policy > > statements from each of them. > Marking a zone delegation-only doesn't imply that it is suitable for logging, so wouldn't participation in any logging scheme require an individual policy statement > anyway? DNS audit logs could decide to only log parents that are delegation-only. To protect themselves and to advocate for parents adding this extra transparency / security to their zone. > > Finally, a DELEGATION_ONLY flagged DNSKEY for > > the root zone cannot be overridden easily, as it would require a > > trust anchor update in all validating resolvers. > The preceding sentences deal with the lingering "false child key" problem, which still applies here, so I don't understand the relevance of this sentence. I agree. I removed the sentence > I also had some thoughts on the Security Considerations: > > > Care should be taken by resolvers to not > > unnecessarily empty their cache. This is specifically important for > > roaming clients that re-connect frequently to different wireless or > > mobile data networks. > I believe this advice is counter to best practices for mobile clients for both performance and privacy reasons. See e.g. http://dnscookie.com/. I read up on that page but the information there is not very detailed. I _think_ that forgetting a cached entry before its TTL is up, would actually expire this dnscookie faster? So you would become less trackable? > Also, I think it's worth mentioning that "delegation-only" zones can still deny the existence of a DS for the child (if the child was signed to begin with), and then > generate deep unsigned records for the child. This limits the direct impact of this flag to cases where DNSSEC is mandatory. (Logging might be able to deter this > attack, assuming NSEC records are logged.) Any zones under the (signed) parent that are not signed are completely untrustworthy anyway. We cannot help these zones. Any of their data can be spoofed by anyone in the forwarding chain. A rogue parent changing or modifying the DS set cannot be prevented, but can only be logged. When we mention DS logging, that includes the logging of the absence of a DS record. So that includes any switching of the zone from secure <-> insecure. 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