Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
Paul Wouters <paul@nohats.ca> Thu, 30 July 2020 20: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 A1A5D3A0C99 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 13:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Y2R5Tb3eKK5V for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 13:28:41 -0700 (PDT)
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 044643A0C94 for <dnsop@ietf.org>; Thu, 30 Jul 2020 13:28:40 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BHhng2rPnz5T4; Thu, 30 Jul 2020 22:28:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1596140919; bh=XUo18Gxad2AEr0o1zErUUkp8F+dSWk6GVthADtCrHW8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MOsgT0UvTvYEae6Herps9n7czF5g+iExqCIvU5KCS3xHvJ5pCTDkGhjWEgA0NkokV iy6udeTbdyTci9bR+0VXpC75IjEcqa6K4j3fAFruulP9hyT957RI2T2ck9dvCr455Z uEkihjluZ4LDjlZU+vBslAvAugkWTEWwHFnRAuT0=
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 eO76BmifItnI; Thu, 30 Jul 2020 22:28:37 +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 22:28:37 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 523F56029BA4; Thu, 30 Jul 2020 16:28:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4A0E2669F1; Thu, 30 Jul 2020 16:28:36 -0400 (EDT)
Date: Thu, 30 Jul 2020 16:28:36 -0400
From: Paul Wouters <paul@nohats.ca>
To: Ben Schwartz <bemasc@google.com>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <CAHbrMsDoYO_hsuCjLeg9pwut_dB703uJ6tgGV0NDq_5sSUWJwA@mail.gmail.com>
Message-ID: <alpine.LRH.2.23.451.2007301546120.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>
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/5tKisyOvO1XHoihrx_eFBBzUxTE>
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 20:28:45 -0000
On Thu, 30 Jul 2020, Ben Schwartz wrote: > I do not believe that is correct. The first and foremost purpose is for > the bit to signal the parent zone's behaviour in a public way that > prevents targeted / coerced attacks from the parent. > > I would love to see some more description of these attacks in the draft. I'm a bit confused that you think describing that in more detail helps. We are talking about fairly simple records like the .ca zone publishing: nohats.ca IN DS blob + RRSIG(key of .ca) nohats.ca IN NS ns0.nohats.ca. ns0.nohats.ca IN A 193.110.157.101 while also (targetted per victim or within a certain time frame) publishing: _443._tcp.nohats.ca IN TLSA blob + RRSIG(key of .ca) www.nohats.ca IN A <malicious IP> + RRSIG(key of .ca) nohats.ca IN MX 0 tapbox.ca. + RRSIG(key of .ca) But I can add this if you feel it helps. > Does the targeted attack still> apply if the recursive resolver does QNAME minimization? It is unrelated to query minimalization, other than that targetted attacks in response to specific queriers is harder. > From the current text, I'm having trouble understanding why it matters whether the attacker has to > generate a fake child zone or not (in the absence of transparency). The attacker could do the above (or even just present glue pretending the nohats.ca is unsigned, thereby leaving out cryptographic traces). If it is forced to generate a new DS for his attack to succeed, and they are forced to publish this at large (eg because query minimalization) then any monitoring of DS records will get them caught. > My "null hypothesis" throughout is that > > 1. zone owners can simply tell me their delegation policy if I email them to ask, and This does not scale and cannot be used to automate behaviour of DNS servers in marking malicious responses as bogus or not. > 2. participation in a logging scheme would require manual review and approval anyway, because > delegation-only zones could still be inappropriate to log, either because they have privacy concerns or > because they would spam the logs. I think you are confused about transparency. The zone owner does not do any kind of submittion to a CT log. Instead you monitor your own or people at large monitor the domains they know or care about or find via recursive query logs to keep a list of when its DS records have changed. This requires no permission of the zone owner and does not involve any agreement about whether producing DS record logs is "appropriate" or not. > for a stronger case. Perhaps we can make logging opt-in part of the flag definition? Or perhaps we can > signal it by the use of NSEC instead of NSEC3? I don't see this being relevant. Also NSEC vs NSEC3 has different hardware requirements and unrelated privacy considerations. > One you know a zone is delegation only, the only way this zone can still > try to violate its own policy is to replace the child delegation with > its own. Therefor, you only need to log DS records that will show you > > there is a child zone change. And resolvers can drop any Answers DNSSEC > signed outside the apex as bogus. Therefor, the parent won't even try > to do this and we dont have to log all its queries. > > But if the parent zone is delegation-only, then there won't be anything else to log except in case of > violation, so these two logs are normally the same size. You need to have that bit that TELLS you the zone is delegation-only without involving humans, management of humans and management of TLD data, update management policies, etc. Yes, once you have that bit, the transparency log is reduced to the violation cases, although you could not boter with logging the futile attempts that would result in the DNS server dropping the data as bogus anyway (although you might want it as proof that their DNSSEC key was used abnormally) > Without this bit, even if we know ".ca" is defacto a delegation only > zone, we have no mechanism to drop records violating this policy without > maintaining a public suffix list type within the resolver or using some > RBL type queries to more dynamically determine the delegation-only > aspect. So now we need to log things like _443._tcp.nohats.ca. IN TLSA > records if signed by something higher than nohats.ca because we can > no longer declare such records as "harmlessly dropped as bogus" and > we simply cannot tell if the record is legitimately signed or not. > > > But how would such a signature come to exist, if ".ca" is a defacto delegation-only zone? While we at IETF and ICANN might have confidence that the root key or some TLD keys will never be abused, the fact that these zones have the power to use these keys for these kind of actions is what some very vocal people in the infosec community keep hammering on as why you cannot trust DNSSEC. This bit is specifically meant to increase that trust. > Logging is not done by the publishers (zone owner) like in CT. Logging > would be done by DNS resolvers in some privacy preserving shared method. > > The draft says that universal logging "would require zone owners to expose all their zone data ... thereby > introducing privacy implications". This seems to apply whether or not the zone is delegation-only, so DNS > resolvers would be violating this proposed privacy principle unless the zone somehow indicates that it > opts in to logging. That statement applied to when we do not have this bit and we would want to ensure no queries every violated the implicit delegation-only role. Again there is no "submission" of zone data to a log anywhere in this system by the authoritative zone operator. I will talk to Wes about changing this text. > On an empty DNS cache, I'm quite literally broadcasting the largest DNS > fingerprint possible to identify my. My only change at hiding is to have > a local DNS cache. > > > If you move IP addresses without wiping your DNS cache, your cached DNS entries become a supercookie by > which a distant server can reidentify you across the network. That is why you use prefetching and ideally the resolver you are using also uses prefetching, so that hot data (eg data that is regularly queried for while it is still in the cache) is pre-fetched before expiry. And no direct IP link exists between you and the auth server. I think supercookies would be easier to do if I'm forced to re-query everything I have all the time. > As such, I've been told that the best > practice for privacy is to bind the cache to a single interface and IP. I would love to see a draft on > this topic, especially if you think this is actually not the best behavior for privacy. I don't think it is. > The last thing I care about is 20ms speedup for some > web page content - the ones who care about those 20ms are the ad auction > participants, not me. > > In case it isn't clear, the concern here is about incorrect network localization of DNS responses. This > is particularly important when using CDN nodes that are _inside_ an ISP, and are intended for (or perhaps > even restricted to) serving that ISP's customers. However, it's true that this is primarily about small > performance gains. While that could be important and nice to have for my TV or playstation, I'm not concerned with that for my phone or laptop. Especially since my mobile devices already VPN across the planet, and are often at coffeeshops and hotels where I wish my only problem was a 20ms delay. > 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.) > > No they cannot generate "deep unsigned records". Their zone is signed, > so if they are not adding a zone cut / delegation, then they have to sign > it or else DNSSEC validating resolvers will drop those queries as bogus > (missing RRSIG). > > Yes they can deny the existence of a child, but that too needs a > signed record of non-existence (NSEC or NSEC3) which would be logged by > transparancy clients logging DS or proof of non-existence of DS. > > > Yes, as I noted, this mechanism can deter this attack, but it cannot prevent it. Nothing can prevent a parent from repurposing a child. It is inherent in the DNS hierarchy. It's a small price to pay for being able to recover your domain via legal proceedings, or from losing your private keys, which is true for all "decentralized DNS" proposals. > The power to change A/AAAA is not what anyone is really trying > to prevent. The prevention is mostly for records with public keys of > fingerprints, such as TLSA, SSHFP, IPSECKEY, eSNI and what not. > > Yes, but nothing in the draft mentions this ... We can add a note to say that anyone in your path can reroute packets to their own network, thereby pretending to be any target IP address you have, and as such, there is little value in preventing this takeover at the DNS layer. I guess we could add that but then also need to talk about on-path vs off-path attackers. I personally feel that is getting rather out of scope for the draft. > nor its converse, that the draft only prevents targeted > attacks in use cases that already mandate DNSSEC. I don't talk about DNS without DNSSEC. Without DNSSEC, you are running a flawed vulnerable version of DNS. One of the largest mistakes of the IETF has been that it has been so afraid of stating this, that it has actually given people reason to think no-DNSSEC is a viable "alternative". It's like trying to secure telnet because you don't like ssh. 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