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

From: Paul Wouters <[email-masked]>
Date: Thu, 4 Nov 2021 20:07:19 -0400 (EDT)

On Tue, 26 Oct 2021, Peter Thomassen wrote:

> This draft introduces automatic bootstrapping of DNSSEC delegations. It uses 
> an in-band method for DNS operators to publish information about the zones 
> they host, per-zone and with authentication. With this protocol, DS 
> provisioning can happen securely and without delay.

I've read the draft, and it is an interesting idea. Some thoughts I had:

- Is it really needed to do hashing? Do we really expect domain names to
   hit the 63 or 255 limit ? 
- _boot seems too generic a name for this. _dsbootstrap would be better
   and cause less clashing
- I would like to see some text on removing the records too once the
   child gained its DS record.
- Should it be explicitly noted that in-bailiwick domains are not
   supported?
- It puts a constraint of the nameserver being in a zone that is DNSSEC
   enabled. This is currently not required (though very often the case
   anyway)

In general, the problem is that we need to make it easier for the DNS
hoster to enable DNSSEC when their customers are non-technical. I think
this draft does properly extend RFC 8078 and even think this document
could deprecate the "Accept after wait" method. However, I do think it
should still impose a minimum length of publication before accepting,
so that mistakes similar to the recent slack.com outage can be
prevented. So change "accept after wait" to "verify, then accept after
wait".

Paul

---

From: "John Levine" <[email-masked]>
Date: 4 Nov 2021 20:40:39 -0400

>   hit the 63 or 255 limit ? 

Probably not.  There was also some thought that this makes it harder for
tourists to guess the delegated zone names, not sure if anyone would care.

>   child gained its DS record.

That really needs to be about scaling issues.  If your NS serves three
zones and you leave in the _boot records, who cares.  But there are
NS that serve three million zones and I think we would all like to
avoid long useless NSEC walks.

>- Should it be explicitly noted that in-bailiwick domains are not

Yes, I thought that was in there already.  I did some counts in TLD
files and found that in practice very few 2LDs use in-bailiwick NS.
We should document it but it's not a big deal.

>   enabled. This is currently not required (though very often the case

The point of this is to do a DNSSEC bootstrap that is fully DNSSEC
validated.  If the _boot record doesn't have to be signed, you might
as well just use the CDS from the child server.

R's,
John

---

From: Peter Thomassen <[email-masked]>
Date: Tue, 9 Nov 2021 01:29:34 +0100

On 11/5/21 1:07 AM, Paul Wouters wrote:
>> This draft introduces automatic bootstrapping of DNSSEC delegations. It uses an in-band method for DNS operators to publish information about the zones they host, per-zone and with authentication. With this protocol, DS provisioning can happen securely and without delay.
> 

Regarding hitting length limits:

- IPv6 reverse DNS hostnames (under ip6.arpa.) already have length 73.
   I wouldn't dare make a prediction about what kind of names could be
   introduced in the next decade (think of underscore labels for TLS
   identities, perhaps with other parameters encoded in front etc.).
   I'd rather be conservative on exhausting the available length limits.

Other technical considerations:

- Not hashing creates semantic collisions.  Practical example from our
   deployment at deSEC:  The list of delegations under dedyn.io is long
   and changes frequently, so we'd probably like to put bootstrapping
   records for children of dedyn.io into a separate zone.
   Without hashing, that zone would be dedyn.io._boot.<NS>.If we do
   that, then we can't use bootstrapping for dedyn.io itself, because
   dedyn.io._boot.<NS> would be an apex name.  This collides with the
   requirement that bootstrapping records MUST NOT occur at the apex
   (where they would signify *that* zone's own DS info).

- This problem generally occurs with public suffixes.  For example,
   when bootstrapping a TLD, you wouldn't be able to create a separate
   bootstrapping zone for its children.  Of course, that's an unlikely
   case, but I think the protocol should be agnostic about that.

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

- When bootstrapping a child with a private parent (e.g. in a corporate
   namespace), hashing the child's immediate ancestor gives a privacy
   benefit even when NSEC walking is allowed (for discovering pending
   bootstrappable names).  (Of course, the benefit is limited, and
   counterarguments similar to the ones against NSEC3 can be made.)

Are there any conceptual downsides of the hashed label that would
outweigh these points?

If not, then the draft should perhaps be more explicit about the above.

> - _boot seems too generic a name for this. _dsbootstrap would be better

Agreed, tracking here:
https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/5

>    child gained its DS record.

There is text on that in the last paragraph on Section 4.1.  Should it
be expanded or moved to a more promiment place?

> - Should it be explicitly noted that in-bailiwick domains are not

I think that would be good. Tracking here:
https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/6

>    enabled. This is currently not required (though very often the case

Yes, prevalence of that is surprisingly high (currently about 25% of
domains in the Tranco 1M toplist).  This protocol would be a reason to
increase that number, as are other protocols (such as parameters for
TLS between resolver and auth, as proposed elsewhere).

> prevented. So change "accept after wait" to "verify, then accept after

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.

Thanks,
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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Nov 2021 21:29:02 -0500 (EST)

On Tue, 9 Nov 2021, Peter Thomassen wrote:

>>>  This draft introduces automatic bootstrapping of DNSSEC delegations. It
>>>  uses an in-band method for DNS operators to publish information about the
>>>  zones they host, per-zone and with authentication. With this protocol, DS

But would they hit 255 ?

>   identities, perhaps with other parameters encoded in front etc.).

Per definition, you can create domain names that are too long to support
_underscore labels on top of them. And yet there we did not use hashing
either?

>   I'd rather be conservative on exhausting the available length limits.

There is something to be said for keeping thing simple too, and more
human debuggable. Hashes don't make that easy.

>   (where they would signify *that* zone's own DS info).

You can't bootstrap in-baliwick anyway, can you?

Also if your nameserver name is not in a zone protected by DNSSEC,
you cannot use it in this scheme to deploy either I thought?

>   case, but I think the protocol should be agnostic about that.

You could simply use a different _label for the two cases. I did not
like _boot anyway as it is too generic, so perhaps you could use
_dnssec_bootstrap and _dnssec_hosted_bootstrap or something similar.
>   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.

>   counterarguments similar to the ones against NSEC3 can be made.)

Yeah.

> Are there any conceptual downsides of the hashed label that would

Yes. Speaking of NSEC3, that is super hard for people to grasp. To us
experts it is obvious, but all the hashes makes a new person who looks
at it pretty confused. I think it would be good in general to try and
make it so that operators can debug DNS issues with the dig command,
without needing advanced tools.

> https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/5

Thanks!

> be expanded or moved to a more promiment place?

I missed that. Perhaps it would be good to give it is own section. We
all know now how bad TXT records at the APEX are now, and anything to
repeat such a thing again would be good.

> https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/6

Thanks.

> TLS between resolver and auth, as proposed elsewhere).

You make me feel old and cynical :)  Anyway, it was just a note. I think
those DNS hosters that want to secure their customer zones better with
DNSSEC will also be running their own domain on their own infrastructure
with DNSSEC. So I don't think this is an issue.

> processing already requires checking that updated DS records don't

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.

Paul

---

From: Peter Thomassen <[email-masked]>
Date: Tue, 9 Nov 2021 04:55:12 +0100

>> - IPv6 reverse DNS hostnames (under ip6.arpa.) already have length 73.

No, this was only an illustration: Had there been some standard which
prevented such long names, then IPv6 reverse DNS names would not have
been possible. But, luckily, nothing go in the way.

We don't know how long names will be in the future, and what will get
in whose way.

> _underscore labels on top of them. And yet there we did not use hashing

When adding labels (e.g. an underscore label) in front of a domain
name, the name of the parent / origin is fixed, so hashing it isn't an
option.  It's not possible to change the length of the suffix.

However, it's possible to choose the length of the prefix that is being
added, and it may make sense to make sure it's not unnecessarily long.

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

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.

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.

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

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.

We therefore cannot put dedyn.io's bootstrapping records at
dedyn.io._boot.ns1.desec.io, as this is a zone apex, and putting
CDS/CDNSKEY records there would indicate that the DS records for the
zone "dedyn.io._boot.ns1.desec.io" should be updated, as opposed to
signaling bootstrapping records for the zone "dedyn.io".

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.

In contrast, the bootstrapping records for dedyn.io *itself* would live
at dedyn.h(io)._boot.ns1.desec.io.  No collision occurs.

Note that this is not an apex name, even if h(io)._boot.ns1.desec.io is
made a separate zone for operational reasons.  Similary, the name for
bootstrapping of example.dedyn.io is not an apex name, even if
h(dedyn.io)._boot.ns1.desec.io is made a separate zone.

It is unclear to me how such situations would properly be dealt with if
the bootstrapping owner names retained the target domains' hierarchy.
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?

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.

The hash ensures that *different things* get *different names*.
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.

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

> without needing advanced tools.

I think the main confusion about NSEC3 stems from the iterations stuff
and from sophisticated denial-of-existence, including when wildcards
are in the game.  We have none of that here.

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.

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

> hold the route hijacks up. So waiting a day would really offer a lot

Fair enough.  I made a note to add a sentence along those lines.

Thanks for your input!
Peter

https://desec.io/

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

---

From: Nils Wisiol <[email-masked]>
Date: Tue, 09 Nov 2021 12:10:33 +0100

On Tue, 2021-11-09 at 04:55 +0100, Peter Thomassen wrote:
> 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.

Following Peter's argument, a solution that avoids hashing requires to
use new record types for bootstrapping in order to avoid confusion with
the original meaning of CDS/CDNSKEY records. This would increase
implementation work for the proposal quite a lot, as currently no
changes to popular auth NS software is needed.

Nils

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Nov 2021 09:56:44 -0500 (EST)

[ cut hashing or not discussion, can be done later ]

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

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

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

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

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

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

> the bootstrapping owner names retained the target domains' hierarchy.

Can you explain why the above wouldn't work ?

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

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

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

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

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

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

> 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

---

From: Peter Thomassen <[email-masked]>
Date: Tue, 9 Nov 2021 16:53:33 +0100

Hi Paul,

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

> confusing. Maybe use "target domains" or "customer domains" instead of

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.

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

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

> and DS for _boot.dedyn.io, or TLD._boot.dedyn.io without needing to

I am not following.

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

> prefix them into the _boot zone?

Only if you enforce there are no delegations there, within the _boot
zone.

> with only ns2 as its nameserver?

I am not following.

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

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

> 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

https://desec.io/

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Nov 2021 16:53:56 -0500 (EST)

> these domains, with prefixes example.com._boot and

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.

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

> when they occur at an apex.)

I still don't see the APEX problem?

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

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.

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

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

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

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

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

> You only need a validation path to exist for each NS hostname (and the

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.

>>  and DS for _boot.dedyn.io, or TLD._boot.dedyn.io without needing to

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.

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

> Only if you enforce there are no delegations there, within the _boot

See above. I think you can.

>>  with only ns2 as its nameserver?

I was trying to say that I think these all work fine, with or without
delegations in the FQDN path of the bootstrap names.

> - They could mean "thing 1", i.e. bootstrapping records for dedyn.io

Yes.

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

> meaning of CDS/CDNSKEY records at that name silently changes.

But the meaning only changes from one invalid use to another invalid
use?

> 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

---

From: Christian Elmerot <[email-masked]>
Date: Wed, 10 Nov 2021 14:18:17 +0100

Coming a bit late to the discussion

> <blob>._boot.ns1.desec.io zone.

<implementer hat on>
Without hashing involved it would be possible to delegate the 
bootstrapping zone(s) to a live service. Hashing requires 
precomputation, which would detract and delay implementation. It would 
be simple to map example.com on top of example.com._boot.ns1.server.name

> document, you could simply say "no bootraps are allowed under a _boot"

I agree. This would be a clarification of CDS/CDNSKEY records since this 
work is already adding additional use of the records beyond 
child->parent signalling.

> delegations deep dnssec bootstraps, or if they do, a 7*1 day delay is

I agree.

> signing the domains and creating CDNSKEY/CDS records for them?

I'd like to think that any such a large number would be easiest served 
by a "live" non-hashed implementation. Adding delegations is far messier

> hashing and not using it to go two delegations deep over unsigned 

Hashing complicates matters more than the issue it solves. A quick (but 
not exhaustive) check suggests that none of the zones we (Cloudflare) 
would be using this for would be affected. It also complicates 
implementations and debugging for all zones while solving the 
bootstrapping issue for a minute number of zones with long names.

/Christian

---

From: Peter Thomassen <[email-masked]>
Date: Tue, 30 Nov 2021 01:31:16 +0100

On 11/5/21 1:07 AM, Paul Wouters wrote:
> could deprecate the "Accept after wait" method.

I took a shot at that in -03.

> However, I do think it

Sure. The draft currently says in Section 3.2:
| If the above steps succeed without error, the CDS/CDNSKEY records are
| successfully validated, and the Parental Agent can proceed with the
| publication of the DS record set under the precautions described in
| [RFC8078], Section 5.

... and there, it says:
| A parent SHOULD [...] ensure
| that the zone validates correctly if the parent publishes the DS
| record.  A parent zone might also consider sending an email to its
| contact addresses to give the child zone a warning that security will
| be enabled after a certain amount of wait time -- thus allowing a
| child administrator to cancel the request.

I think that from a technical perspective, that covers the policy you're proposing.

Or did you really mean to *impose* a minimum delay, as in: it is forbidden to deploy more quickly?

Another approach would be to re-state explicitly what's in RFC 8078 Section 5 (but I don't know if text duplication between RFCs is welcome?).

Best,
Peter