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
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 ?
Regarding hitting length limits:
- IPv6 reverse DNS hostnames (under ip6.arpa.) already have length 73.
But would they hit 255 ?
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?
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.
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).
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?
- 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.
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.
- 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.
- 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.)
Yeah.
Are there any conceptual downsides of the hashed label that would
outweigh these points?
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.
- _boot seems too generic a name for this. _dsbootstrap would be better
and cause less clashing
Agreed, tracking here:
https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/5
Thanks!
- I would like to see some text on removing the records too once the
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?
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.
- Should it be explicitly noted that in-bailiwick domains are not
supported?
I think that would be good. Tracking here:
https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/6
Thanks.
- 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)
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).
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.
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".
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.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
