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

[Peter Thomassen]

On 4/27/22 15:11, Bob Harold wrote:

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.


Interesting proposal! When named like

_dsauth.example.com._signal.ns1.desec.io

or similarly, this would suggest that other things could be signaled as well. 
Perhaps this could be useful in other cases.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

(Response at the bottom, nothing inline)

On Tue, Apr 26, 2022 at 11:29 PM Peter Thomassen  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.._boot.ns1.dedyn.io IN CDNSKEY [...]
> > foo.._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 

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

[Peter Thomassen]

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.._boot.ns1.dedyn.io IN CDNSKEY [...]
foo.._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 

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

[Christian Elmerot]

Coming a bit late to the discussion

On 2021-11-09 22:53, Paul Wouters wrote:

On Tue, 9 Nov 2021, Peter Thomassen wrote:


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 ._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 
._boot.ns1.desec.io zone.



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



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




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.


I agree.


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?


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



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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

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.._boot.ns1.dedyn.io IN CDNSKEY [...]
foo.._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 

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

[Peter Thomassen]

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

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

[Paul Wouters]

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

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

[Nils Wisiol]

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

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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter Thomassen]

On 11/9/21 3:29 AM, Paul Wouters wrote:

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


But would they hit 255 ?


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.


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


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?


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.


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..If we do
  that, then we can't use bootstrapping for dedyn.io itself, because
  dedyn.io._boot. 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).


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.