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

[Peter Thomassen <[e-mail]>]

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