Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Bob Harold <[e-mail]>]

(Response at the bottom, nothing inline)

On Tue, Apr 26, 2022 at 11:29 PM Peter Thomassen <[e-mail]> 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 [e-mail] only (this thread is also on
> [e-mail]). 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