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

[Paul Wouters <[e-mail]>]

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

But the DNS is already pretty good at that with FQDNs?

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

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

I'd rather make it more human friendly than support a known broken
implementation :)

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

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

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

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