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

[Peter Thomassen <[e-mail]>]

Hi Paul,

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.

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".

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.)

However, there's nothing wrong with enabling bootstrapping records
for both these domains at once.  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.  (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.)

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.

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.
The only thing that's necessary is that the NS hostname have a
validation path.

>> 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" ?

The example I gave was primarily about dedyn.io and example.dedyn.io;
that's why I made the statement about the children of dedyn.io and
their NS records.

Of course, other zones (such as under .com) can be hosted on the same
nameserver.  That's why I later gave another example of a bootstrapping
zone that may deserve its own delegation (com._boot.ns1.desec.io).
Apologies in case this made things less clear.

>> 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 ?

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.

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.

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.

>> 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).

>> 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.

>> 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.

>> 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.

>> 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.

>> 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
- They could mean "thing 2", that is DS rollover for the bootstrapping
   zone *itself* (dedyn.io._boot.ns1.desec.io)

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.

So, yes, the DNS is good at naming things differently, but we have to
create a naming scheme that is free of collisions.

>> 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.

The whole point of the bootstrapping protocol is to co-publish the
target domain's CDS/CDNSKEY records verbatim under the corresponding
name below _boot.

>> 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.

I absolutely subscribe to this reasoning, but unfortunately it doesn't
make the above problem go away.

Cheers,
Peter

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525