(Response at the bottom, nothing inline) On Tue, Apr 26, 2022 at 11:29 PM Peter Thomassen <pe...@desec.io> wrote:
> Hi Paul, > > Thank you for all your thoughts, which I think we should continue > discussing so that we arrive at something we both agree with. While that's > of course not strictly required, I think it is possible if we twist our > brains a bit more. :-) > > I've spent some time writing down the problem from scratch, in a very > structured way and from rather basic principles. I hope that this way, it > will be possible to point very directly at where my arguments go wrong, so > that I will understand your perspective better. > > As the draft has been adopted now, I think it's better to continue > discussion on dnsop@ietf.org only (this thread is also on > dnssec-bootstrapp...@ietf.org). The fresh write-up is now here: > https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/ > > Note that I'm not specifically arguing for the hashed naming scheme > (anymore). Instead, the new write-up points out a problem that is implicit > in the current draft, and then discusses various possible solutions (the > hashed scheme being but one if them). > > Thanks, > Peter > > > On 11/9/21 22:53, Paul Wouters wrote: > > On Tue, 9 Nov 2021, Peter Thomassen wrote: > > > >> On 11/9/21 3:56 PM, Paul Wouters wrote: > >>>> 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 ? > >> > >> In such a situation, a domain like dedyn.io (which has other subzones > >> on the same nameserver) is not necessarily already being used for > >> bootstrapping. > >> > >> Example: Imagine a DNS operator which supports both DNSSEC and > >> bootstrapping. They have a customer with the zone example.com and > >> a subzone foo.example.com, but DNSSEC is currently off. > >> > >> Suppose the customer turns on DNSSEC in the operator's service portal. > >> What will happen now is that the _boot zones under the operator's > >> nameserver hostnames will be populated with bootstrapping records for > >> these domains, with prefixes example.com._boot and > >> foo.example.com._boot. > > > > I think in this case, you cannot start foo.example.com._boot. because > > its parental agent (which happens to be you too but should still follow > > the RFC) detects that the parent zone example.com is not signed and > > thus cannot perform a bootstrap of foo.example.com. Doing them at once > > would be a race condition. You'd really want to do these one after the > > other. > > > >> Remember, the bootstrapping records are of type CDS/CDNSKEY, and they > >> will now show up both at the level of "foo.example.com._boot" and one > >> level up, at the level of "example.com._boot". > > > > But can't you still publish all of these? like: > > > > in dedyn.io zone (or ns1.dedyn.io zone or _boot.ns1.dedyn.io zoe): > > > > example.<hash-of-example.com>._boot.ns1.dedyn.io IN CDNSKEY [...] > > foo.<hash-of-foo.example.com>._boot.ns1.dedyn.io IN CDNSKEY [...] > > > > in your example.com zone: > > > > example.com. IN CDNSKEY [...] > > > > In your foo.example.com zone: > > > > foo.example.com. IN CDNSKEY [...] > > > >> As a result, the DNS operator is no longer free to make a delegation > >> at "example.com._boot", because that would change the meaning of the > >> bootstrapping records. (CDS/CDNSKEY records have a conflicting meaning > >> when they occur at an apex.) > > > > I still don't see the APEX problem? > > > >> However, there's nothing wrong with enabling bootstrapping records > >> for both these domains at once. > > > > I think there is. You can't boostrap a domain whose parent is not > > already fully DNSSEC enabled. As those parents are not valid candidates > > to take in CDS records. > > > >> There's no reason why DS records for > >> foo.example.com should not be put into example.com while > >> bootstrapping for example.com is running in parallel. > > > > There is because the parent is unsigned and so whatever it is publishing > > about its children is lacking trust. > > > >> (It's not > >> even necessary for example.com to ever be securely delegated, if there > >> is another trust root for it, e.g. in an enterprise setting.) > > > > There is. nothing under example.com will ever DNSSEC validate. It cannot > > make claims abouts its sub delegations via DS records as those DS > > records would be bogus. > > > >> DS bootstrapping does not require the parent of the bootstrapped domain > >> to be secure. The protocol should not concern itself with the chain of > >> trust above the domain that is being bootstrapped. > > > > This intension was not clear to me from reading the draft. You want to > > DNSSEC bootstrap "islands of trust" ? I think that should be out of > > scope. You are then already in enterprise/provisioning territory where > > this provisioning can just be added without this new protocol. > > > >> The protocol should not make any assumptions like that, so that > >> bootstrapping of several domains along the same branch in the DNS tree > >> (e.g. example.com, and foo.example.com) can be fully orthogonal. > > > > I disagree. Sure you can have an island of trust, eg a manually > > configured trust anchor for internal.example.com with a DS trust anchor, > > but then you should still insist on all checks from internal.example.com > > to be securely delegated. So you first have to do > foo.internal.example.com > > before you can do bar.foo.internal.example.com. > > > > While I think this is true from a security and logical point of view, I > > think you will run into practical issues if you are attempting to > > retrieve or publish DS records that lack DNSSEC validation. > > > >> Let's consider the bootstrapping namespace under _boot.ns1.desec.io. > >> There would usually be NS/DS records at this name. > >> > >> However, it should be possible to introduce zone cuts underneath that > >> name, so operators can control the size and churn of the zones involved > >> in bootstrapping. This idea madeit into the draft based on feedback > >> by John Levine, who pointed out that scalability should be a very > >> strong priority. > >> > >> So, there may be additional NS/DS rrsets at com._boot.ns1.desec.io, or > >> dedyn.io._boot.ns1.desec.io. > > > > But then you are most certainly better of without hashing, because then > > you can make a zone for each <tld>._boot.ns1.desec.io. Or when you see > > that foo.tld is a generic domain too that is becoming too large, create > > a zone for foo.tld._boot.ns1.desec.io. > > > > Whereas with hashes, you just have an unpredictable flat <blob>._ > boot.ns1.desec.io zone. > > > >> Adding such a delegation turns the corresponding name into an apex, and > >> thus requires that there are no bootstrapping CDS/CDNSKEY records at > >> that name, because they would silently change in meaning. > > > > Ok, so I think you are saying that for: > > > > example.com._boot.ns1.desec.io. IN CDS [..] > > > > or > > > > example.<hash-of-com>._boot.ns1.desec.io. IN CDS [..] > > > > or > > > > com._boot.ns1.desec.io. IN CDS [..] > > > > That without the <hash> method, having a zone cut at > > com._boot.ns1.desec.io. could somehow change the meaning ? > > > > You would have an NS and DS record for com._boot.ns1.desec.io., but > > not for example.com._boot.ns1.desec.io. where you would have a CDS > > or CDNSKEY. In fact, the lack of NS for example.com._boot.ns1.desec.io. > means > > that you are not using CDS to update a DS. > > > > I don't see the "silently change in meaning" ? > > > >> The problem is that if we now put bootstrapping records at these > >> delegation points, they suddenly take on the meaning of conventional > >> (non-bootstrapping) CDS/CDNSKEY records for these subzones. > > > > So for com._boot.ns1.desec.io. I dont see that happening, but I guess > > if you do both example.com._boot.ns1.desec.io. and > > foo.example.com._boot.ns1.desec.io, then you have: > > > > com._boot.ns1.desec.io. IN NS .... > > com._boot.ns1.desec.io. IN DS .... > > example.com._boot.ns1.desec.io. IN CDS .... > > > > If this last record is treated in the "regular" way, that means that > example.com._boot.ns1.desec.io. > > is signaling to com._boot.ns1.desec.io to update its DS record. But > > there is no zone cut there, so the "traditional" meaning has no effect. > > > > In a way, this is just the same as me publishing www.example.com IN CDS > [...]. No one will ever > > ask for the record since there is no NS for www.example.com. So there is > > no way for "current deployed software" to do anything wrong. In your > > document, you could simply say "no bootraps are allowed under a _boot" > > delegation. > > > > I don't think this issue is improved by using hashes. > > > > Now let's say you want to use CDS for com._boot.ns1.desec.io. to notify > boot.ns1.desec.io. > > > > You would publish: > > > > com._boot.ns1.desec.io. IN CDS .... > > > > Now someone could think you are boosttrapping for com. Someone could > > fake the (unsigned) com NS records to be ns1.desec.io. And they could > > possible convince com's parent to do dnssec bootstrap. If the attacker > > manages to trigger the boostrap in com's parent, the parent would still > > find com is either A) already signed so only CDS in com directly can be > > used to update, not this bootstrap, or B) unsigned, in which case I > > again press my point that nothing under an unsinged delegation should > > qualify for booststrap anyway. Still the common non-attack case here > > would be that com has no nameserver ns2.desec.io so the bootstrap would > > be aborted. Meanwhile, your nameservers involved in the com._ > boot.ns1.desec.io. > > and _boot.ns1.desec.io zones can still use regular CDS updating, > > verifying the CDS/CDNSKEY is really in use for that domain and proceed > > with publication of the updated DS record. > > > >>>> 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 ? > >> > >> You don't need that. > >> > >> You only need a validation path to exist for each NS hostname (and the > >> _boot zone underneath). > > > > We disagree. I think the boostrap should only extend the validation path > > from a parent zone to the child zone. It should not try to skip a > > zonecut in the hierarchy. Yes this causes a delay to deploy, but you > > need some delay for security anyway and people won't be deploying 7 > > delegations deep dnssec bootstraps, or if they do, a 7*1 day delay is > > fine. > > > >>>> 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? > >> > >> I am not following. > > > > the boostrap is usually needed to bridge the gap of Registrar and DNS > > Hoster. If the DNS hoster already has signed dnshoster.com, then they > > can just atomically create NS/DS records for _boot.ns1.dnshoster.com. > > They are not depending on another party that lacks the automation to > > deploy DNSSEC. > > > >>>> 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 ? > >> > >> In the general case, there will be a collision between bootstrapping > >> records and conventional apex-level CDS/CDNSKEY records, unless > >> delegations within the _boot subtree are prohibited. > > > > Yes :) But I hope I managed to point out you can still use CDS/DS within > > your bootstrap without the double meaning of the names outside the > > bootstrap chain. > > > >>>> 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? > >> > >> Only if you enforce there are no delegations there, within the _boot > >> zone. > > > > See above. I think you can. > > > >>>> 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? > >> > >> I am not following. > > > > I was trying to say that I think these all work fine, with or without > > delegations in the FQDN path of the bootstrap names. > > > >>>> The hash ensures that *different things* get *different names*. > >>> > >>> But the DNS is already pretty good at that with FQDNs? > >> > >> The DNS provides sufficient naming capabilities, yes. My point is that > >> in your proposal, when dedyn.io and its children are hosted on the same > >> nameserver, two different things will turn up with the same name: > >> > >> 1.) the name of the bootstrapping records for dedyn.io > >> 2.) the name of the zone containing bootstrapping records for children > >> of dedyn.io > >> > >> The name in question is: dedyn.io._boot.ns1.desec.io > >> > >> CDS/CDNSKEY records at that name can now mean two things: > >> > >> - They could mean "thing 1", i.e. bootstrapping records for dedyn.io > > > > Yes. > > > >> - They could mean "thing 2", that is DS rollover for the bootstrapping > >> zone *itself* (dedyn.io._boot.ns1.desec.io) > > > > No? > > > > If your zone cut is at io._boot.ns1.desec.io or _boot.ns1.desec.io, then > > CDS dedyn.io._boot.ns1.desec.io does not have a traditional (C)DS > record meaning, > > as there is no NS (zonecut) for dedyn.io._boot.ns1.desec.io. > > > > If your zone cut is at dedyn.io._boot.ns1.desec.io because you have many > > delegations for <customers>.dedyn.io then the interpretation of CDS > cannot > > be for boostrap because dedyn.io is already DNSSEC signed (or else you > > cannot / should not accept secure delegations for <customers>), so its > > intepretation is always for a classic DNSKEY roll signaling of the zone > > dedyn.io._boot.ns1.desec.io to its parent (either io._boot.ns1.desec.io > > or _boot.ns1.desec.io or ns1.desec.io or even desec.io). If you would > > try to mean it as this protocol and old software reads it as > > traditional, that software would abort too if it is unsigned. So I don't > > think you can accidentally break things either? > > > >> It's not explicit what's meant, so there's an ambiguity. Worse, if > >> you add or remove the delegation at dedyn.io_boot.ns1.desec.io, the > >> meaning of CDS/CDNSKEY records at that name silently changes. > > > > But the meaning only changes from one invalid use to another invalid > > use? > > > >> So, yes, the DNS is good at naming things differently, but we have to > >> create a naming scheme that is free of collisions. > > > > I am not convinced. See above. I think it is clear based on where the > > (C)DS records are and who would even query for it at that particular > > location. > > > > I don't think it helps scaling either because large zones are pretty > > trivial these days and all these records are fairly short lived > > (days). I doubt we will see 60M of these on 1 nameserver. Can you (or > > John) explain what you think is the scale that would no longer work on > > a DNSSEC system? And how would that scaling compare to the CPU/disk > > required to generate new DNSKEYs for all those new DNSSEC domains, > > signing the domains and creating CDNSKEY/CDS records for them? > > > > And regardless, you can create delegatations for com._boot just as > > easilly as <hash-of-com>._boot. > > > > I think it only helps prevent hitting the theoretical but non-real > > FQDN limit of 255, but as I said before, anything that prepends an > > _underscore prefix will always have a limit under 255. Not using hashes > > would reduce the max length to 128 minues the _boot prefix length versus > > 255 - 64 (length of base64(sha256)) - _boot prefix length. So more or > > less reduce support of FQDNs from ~200 to ~128. This already requires a > > minimum of 3 subdelegations, but since most TLDs dont exceed ~10 to > > ~20, would require 4+ delegations. At which point you should really be in > > part of the DNS tree where you control all parties to provision zones > > without needing the bootstrap, that is mainly aimed at Registrar - DNS > > Operator limitations. Eg you would be using catalog zones with your > > nameservers that would be able to do CDS -> DS because of existing XFR > > or NSUPDATE based trust relationships, or would even run on the same > > nameserver to completely automated DS updates when hosting both child > > and parent. > > > > Anyway, just to reflect, I _do_ like and this idea, but strongly prefer > no > > hashing and not using it to go two delegations deep over unsigned > parents. > > > > Paul > To avoid (C)DS at an apex under the _boot tree, one could use another _name like: _nsboot.dedyn.io._boot.ns1.desec.io. CDS ... So the CDS records in this new scheme are never at an apex, but one level down under a new "_nsboot" label. It adds another label, but avoids any ambiguity. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
