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

[Christian Elmerot <[e-mail]>]

Coming a bit late to the discussion

On 2021-11-09 22:53, Paul Wouters wrote:
> On Tue, 9 Nov 2021, Peter Thomassen wrote:
>
>> Let's consider the bootstrapping namespace under _boot.ns1.desec.io.
>> There would usually be NS/DS records at this name.
>>
>> However, it should be possible to introduce zone cuts underneath that
>> name, so operators can control the size and churn of the zones involved
>> in bootstrapping.  This idea madeit into the draft based on feedback
>> by John Levine, who pointed out that scalability should be a very
>> strong priority.
>>
>> So, there may be additional NS/DS rrsets at com._boot.ns1.desec.io, or
>> dedyn.io._boot.ns1.desec.io.
>
> But then you are most certainly better of without hashing, because then
> you can make a zone for each <tld>._boot.ns1.desec.io. Or when you see
> that foo.tld is a generic domain too that is becoming too large, create
> a zone for foo.tld._boot.ns1.desec.io.
>
> Whereas with hashes, you just have an unpredictable flat 
> <blob>._boot.ns1.desec.io zone.

<implementer hat on>
Without hashing involved it would be possible to delegate the 
bootstrapping zone(s) to a live service. Hashing requires 
precomputation, which would detract and delay implementation. It would 
be simple to map example.com on top of example.com._boot.ns1.server.name


> In a way, this is just the same as me publishing www.example.com IN 
> CDS [...]. No one will ever
> ask for the record since there is no NS for www.example.com. So there is
> no way for "current deployed software" to do anything wrong. In your
> document, you could simply say "no bootraps are allowed under a _boot"
> delegation.

I agree. This would be a clarification of CDS/CDNSKEY records since this 
work is already adding additional use of the records beyond 
child->parent signalling.


> We disagree. I think the boostrap should only extend the validation path
> from a parent zone to the child zone. It should not try to skip a
> zonecut in the hierarchy. Yes this causes a delay to deploy, but you
> need some delay for security anyway and people won't be deploying 7
> delegations deep dnssec bootstraps, or if they do, a 7*1 day delay is
> fine.

I agree.

> I don't think it helps scaling either because large zones are pretty
> trivial these days and all these records are fairly short lived
> (days). I doubt we will see 60M of these on 1 nameserver. Can you (or
> John) explain what you think is the scale that would no longer work on
> a DNSSEC system? And how would that scaling compare to the CPU/disk
> required to generate new DNSKEYs for all those new DNSSEC domains,
> signing the domains and creating CDNSKEY/CDS records for them?

I'd like to think that any such a large number would be easiest served 
by a "live" non-hashed implementation. Adding delegations is far messier

> I think it only helps prevent hitting the theoretical but non-real
> FQDN limit of 255, but as I said before, anything that prepends an
> _underscore prefix will always have a limit under 255. Not using hashes
> would reduce the max length to 128 minues the _boot prefix length versus
> 255 - 64 (length of base64(sha256)) - _boot prefix length.  So more or
> less reduce support of FQDNs from ~200 to ~128. This already requires a
> minimum of 3 subdelegations, but since most TLDs dont exceed ~10 to
> ~20, would require 4+ delegations. At which point you should really be in
> part of the DNS tree where you control all parties to provision zones
> without needing the bootstrap, that is mainly aimed at Registrar - DNS
> Operator limitations. Eg you would be using catalog zones with your
> nameservers that would be able to do CDS -> DS because of existing XFR
> or NSUPDATE based trust relationships, or would even run on the same
> nameserver to completely automated DS updates when hosting both child
> and parent.
>
> Anyway, just to reflect, I _do_ like and this idea, but strongly 
> prefer no
> hashing and not using it to go two delegations deep over unsigned 
> parents.

Hashing complicates matters more than the issue it solves. A quick (but 
not exhaustive) check suggests that none of the zones we (Cloudflare) 
would be using this for would be affected. It also complicates 
implementations and debugging for all zones while solving the 
bootstrapping issue for a minute number of zones with long names.

/Christian