On 11/5/21 1:07 AM, Paul Wouters wrote:
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 ?
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
and cause less clashing
Agreed, tracking here:
https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/5
- 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?
- 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
- 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).
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.
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
