Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
Paul Wouters <paul.wouters@aiven.io> Tue, 09 November 2021 14:57 UTC
Return-Path: <paul.wouters@aiven.io>
X-Original-To: dnssec-bootstrapping@ietfa.amsl.com
Delivered-To: dnssec-bootstrapping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA4F3A0DE9 for <dnssec-bootstrapping@ietfa.amsl.com>; Tue, 9 Nov 2021 06:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_PASS=-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=aiven.io
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 JuhgYq9M711m for <dnssec-bootstrapping@ietfa.amsl.com>; Tue, 9 Nov 2021 06:56:55 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 D84013A0DDC for <dnssec-bootstrapping@ietf.org>; Tue, 9 Nov 2021 06:56:54 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id m14so77229779edd.0 for <dnssec-bootstrapping@ietf.org>; Tue, 09 Nov 2021 06:56:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=bpyTswQ/l+4/hN0gOT42vDbA2B9rP/rR9ISM26rQ29c=; b=PPDmohP6+KY5u5g7e7iYUN62qAyDRGRzz15Dibt+HIzmhw8yasLdYAgTf82uFtX2Ti oqlVC61vSKEl34PTozEvpSI38LL95AnG8+njP328QRChaVLalrx6ymKnRoW9ZQGNMtUo lbL0jw7TiWrKR7VLR3qwUuMe8j2n11yv9uI7k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=bpyTswQ/l+4/hN0gOT42vDbA2B9rP/rR9ISM26rQ29c=; b=p0KaFJo60+wC5hOL8vnM9jhb7KnDqKqsvczV/BGuG7rg8hLpt8asdR7YeP1EztaNOT ZvLub2cKm9hbeiozR0vqq9aMpH0T/qrAgDFybd20VQAD8GP+8turXkXxV6bN7I55nJSE Aq6rqEEfGhs3ltU2r0IA7E93ULRvRaDxQ/6Zwx5NyzXnuT46lhgqL5RcdZMw3gH77YQH 1IKchVVnzcIVMWutD3XFfjG0MHqhdgRYVxOYRRDNktdvQvd3jjhT2IVSCcS5Ji1QSto9 cKotnPiT6vUJUO/TBuNb+NeR9KeBoED/C5XXu4FGQHnPBleMUnxSiMY2gIrld3a8qPj4 POuw==
X-Gm-Message-State: AOAM532m/Fbp8SSItkpT/Mpc7fKrQwX5zDg23aG9fCilE3NJQ7fcaQ3U /sqSOq7Vi2FxU+LUR4e64RCmuw==
X-Google-Smtp-Source: ABdhPJxfYR5zG3cf2/kBsYhveif7eEJ5GT0qhbqK6ftGdEyhsw1VwHAulFL6aptFd7z7p6cASxLB9Q==
X-Received: by 2002:a17:907:94c2:: with SMTP id dn2mr10362912ejc.312.1636469812823; Tue, 09 Nov 2021 06:56:52 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id d22sm9976719ejj.47.2021.11.09.06.56.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Nov 2021 06:56:52 -0800 (PST)
Date: Tue, 09 Nov 2021 09:56:44 -0500
From: Paul Wouters <paul.wouters@aiven.io>
To: Peter Thomassen <peter@desec.io>
cc: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>, dnssec-bootstrapping@ietf.org
In-Reply-To: <37fa7324-643a-9c3c-4256-97abe52f1118@desec.io>
Message-ID: <2c8d972a-1388-2f42-994-56a58fe03916@nohats.ca>
References: <163520620129.17275.16274772439094875607@ietfa.amsl.com> <91154628-0ca3-15d8-c6bd-b71232b2e64b@desec.io> <8d3b2ae-70e3-74b4-40a0-70e848acc4aa@nohats.ca> <66e2a81b-b971-cdea-0f40-cfed68be574f@desec.io> <705c1434-532-6840-8ae4-545bde91822@nohats.ca> <37fa7324-643a-9c3c-4256-97abe52f1118@desec.io>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1858192029-209201581-1636469812=:273424"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssec-bootstrapping/aMTyzpNUuy1BN7xjzjQ150shHl8>
Subject: Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
X-BeenThere: dnssec-bootstrapping@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Authenticated Bootstrapping of DNSSEC Delegations <dnssec-bootstrapping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssec-bootstrapping>, <mailto:dnssec-bootstrapping-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssec-bootstrapping/>
List-Post: <mailto:dnssec-bootstrapping@ietf.org>
List-Help: <mailto:dnssec-bootstrapping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping>, <mailto:dnssec-bootstrapping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 14:57:00 -0000
On Tue, 9 Nov 2021, Peter Thomassen wrote: [ cut hashing or not discussion, can be done later ] >> You can't bootstrap in-baliwick anyway, can you? > > There seems to be a misunderstanding: The not-in-bailiwick limitation > means that a nameserver can't bootstrap its own domain, for lack for a > pre-existing validation path. But in the above example, it was not > assumed that any of the zones mentioned has any in-bailiwick NS. right. But then I am confused by: > Now let's consider bootstrapping for dedyn.io *itself* (not one of its > children!). The location of the bootstrapping records for this domain > would be dedyn.io._boot.ns1.desec.io, which is the same as the name of > the *zone* which constains bootstrapping records for domains *under* > dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io. Aren't you saying here that you want to be able to boostrap dedyn.io, meaning it is currently unsigned, while also having a problem with containing its "children", eg it is already used for boostrapping other domains, while it it unsigned yet itself ? > To clear up the misunderstanding, I'll write out the example in detail. > > dedyn.io has NS ns1.desec.io and ns2.desec.org. Children of dedyn.io > typically have the same NS rrset. I'm a bit confused about the term "children" here. Normally in DNS we say children for subdomains/delegations. But further done, you are talking about entrie in .com too, so I think the term children here is confusing. Maybe use "target domains" or "customer domains" instead of the term "children" ? > When a customer registers a new name under dedyn.io (it is a public > suffix), we currently have some kind of hook that creates the DS > records in the dedyn.io zone. Once there is a good bootstrapping > protocol, there should be no need to keep that kludge. Right. But I would assume that this means dedyn.io is already fully DNSSEC enabled. Else any _boot records cannot be trusted as they have no DNSSEC protection. > We would like to use the bootstrapping protocol to enable DNSSEC for > such sub-zones. For that, we have to read the bootstrapping records, > which would be, without hashing, located at something like > example.dedyn.io._boot.ns1.desec.io (sticking to _boot for now). > > Because dedyn.io has a lot of delegations and keeps changing, we'd like > to run bootstrapping for dedyn.io in a separate zone (same for com). > We'd arrive at a setup like this: > > dedyn.io._boot.ns1.desec.io # bootstrapping zone for dedyn.io children > com._boot.ns1.desec.io # bootstrapping zone for com children > _boot.ns1.desec.io # zone for all other bootstrapping Ok, so you want either an NS/DS for _boot.ns1.desec.io or you want individual NS/DS records for <TLD>._boot.s1.desec.io ? > Now let's consider bootstrapping for dedyn.io *itself* (not one of its > children!). The location of the bootstrapping records for this domain > would be dedyn.io._boot.ns1.desec.io, which is the same as the name of > the *zone* which constains bootstrapping records for domains *under* > dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io. So as stated above, I don't think this is a valid use case, as you need the bootstrap already in place ? > This has nothing to do with in-bailiwick. The problem occurs because > bootstrapping records cannot be at the apex (as to not overload the > meaning of apex CDS/CDNSKEY records), but by "inheriting" the structure > under dedyn.io, a situation arises where this condition is not met. > > The solution is to not "inherit", but flatten the hierarchy, which is > what the hash does. With hashing, children of dedyn.io would have > their bootstrapping records under h(dedyn.io)._boot.ns1.desec.io, such > as example.h(dedyn.io)._boot.ns1.desec.io. I would think you could still use exmaple.dedyn.io._boot.ns1.desec.io. (regardless of hashing or not). But you need desec.io to already be DNSSEC signed, and since you control desec.io, it should be trivial to add NS and DS for _boot.dedyn.io, or TLD._boot.dedyn.io without needing to bootstrap? > It is unclear to me how such situations would properly be dealt with if > the bootstrapping owner names retained the target domains' hierarchy. Can you explain why the above wouldn't work ? > One could of course specify that you can only ever bootstrap *one* > name along a certain branch of the DNS tree. But what would be the > motivation for such a limitation? No, you should be able to do all the domains you want, as long as you prefix them into the _boot zone? > I'm sure the situation could be complicated futher by considering more > sophisticated delegation hierarchies (e.g. dedyn.io is at ns1.desec.io, > foo.dedyn.io is not, but bar.foo.dedyn.io is again at ns1.desec.io, and > so on). These are all things the protocol should be ignorant of. I don't think that needs to matter, you can even run NS/DS onto _boot.ns1.dedyn.io with only ns1 as its nameserver and _boot.ns2.dedyn.io with only ns2 as its nameserver? > The hash ensures that *different things* get *different names*. But the DNS is already pretty good at that with FQDNs? > It is a namespacing mechanism, and avoids overloading the names of > bootstrapping records with the names of bootstrapping zones. Such > overloading would be unclean design even if the was no pre-existing use > of CDS/CDNSKEY records at the apex. Not sure where CDS/CDSNKEY comes in, as those live in the target domains zone itself, outside of any _boot prefixed zone. >>> - Clear datastructures simplify implementation (in my experience). >>> Hashing leads to a very predictable data structure with always two >>> labels in front of the underscore label. Also, that label would be >>> an ENT; all records live at the leaves of the tree. This assumption >>> cannot be made when the names are simply concatenated (see above). >> >> ENT's aren't that great :P For example, with query minimalization on >> AWS Route53, these have been broken for years. I'd stay away from ENTs. > > Haha :-) Yes, I'm with you. My point was precisely that without > hashing, you may sometimes get an ENT at a certain hierarchy level and > sometimes you don't, so you'll have to deal with both cases. > > With hashing, you'll only have to deal with the case that there is an > ENT at the hash label, which in turn may simplify debugging etc. I'd rather make it more human friendly than support a known broken implementation :) > I agree about the dig command. But, it's only possible (e.g. for > DNSSEC debugging) because dig has some explicit things implemented, > e.g. options like +multiline or +trace. But I could just easilly without manual hashing, look if the records for ietf.org are in ietf.org._boot.ns1.desec.de are published with dig. Where as if it is hashed, I will need a special tool. > One could thus turn your concern around and say that to aid debugging, > it would be cool if debugging tools like dig would get equipped with > suitable capabilities. ;-) You'd still need to know a lot more about options and what not :) Using simple DNS queries seems nicer to me, and then we can use generic purpose dig :) >>> While I don't feel strongly, I wonder in how many cases somebody would >>> really look at that during that extra wait interval. Also, CDS/CDNSKEY >>> processing already requires checking that updated DS records don't >>> break resolution. >> >> Yes, but if someone accidentally pushes a DNSSEC deployment out and >> pulls it back in after 5 minutes, you don't want this protocol to have >> pushed the machinary into production and causing ServFails. Similarly, >> I find BGP / routing attacks still scary, and attackers can only briefly >> hold the route hijacks up. So waiting a day would really offer a lot >> of protection here. > > Fair enough. I made a note to add a sentence along those lines. Thanks. That is why we put in the original delay too for CDS/CDNSKEY. Paul
- [DNSSEC-Bootstrapping] Fwd: New Version Notificat… Peter Thomassen
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Paul Wouters
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Peter Thomassen
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Paul Wouters
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Peter Thomassen
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Nils Wisiol
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Paul Wouters
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Peter Thomassen
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Paul Wouters
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Christian Elmerot
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Peter Thomassen
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Peter Thomassen
- Re: [DNSSEC-Bootstrapping] [DNSOP] Fwd: New Versi… Bob Harold