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

[Paul Wouters <[e-mail]>]

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