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

[Peter Thomassen <[e-mail]>]

Hi Paul,

Thank you for all your thoughts, which I think we should continue discussing so that we arrive at something we both agree with. While that's of course not strictly required, I think it is possible if we twist our brains a bit more. :-)

I've spent some time writing down the problem from scratch, in a very structured way and from rather basic principles. I hope that this way, it will be possible to point very directly at where my arguments go wrong, so that I will understand your perspective better.

As the draft has been adopted now, I think it's better to continue discussion on [e-mail] only (this thread is also on [e-mail]) The fresh write-up is now here: https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/

Note that I'm not specifically arguing for the hashed naming scheme (anymore). Instead, the new write-up points out a problem that is implicit in the current draft, and then discusses various possible solutions (the hashed scheme being but one if them).

Thanks,
Peter


On 11/9/21 22:53, Paul Wouters wrote:
> On Tue, 9 Nov 2021, Peter Thomassen wrote:
> 
>> On 11/9/21 3:56 PM, Paul Wouters wrote:
>>>>  Now let's consider bootstrapping for dedyn.io *itself* (not one of its
>>>>  children!).  The location of the bootstrapping records for this domain
>>>>  would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
>>>>  the *zone* which constains bootstrapping records for domains *under*
>>>>  dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io.
>>>
>>>  Aren't you saying here that you want to be able to boostrap dedyn.io,
>>>  meaning it is currently unsigned, while also having a problem with
>>>  containing its "children", eg it is already used for boostrapping
>>>  other domains, while it it unsigned yet itself ?
>>
>> In such a situation, a domain like dedyn.io (which has other subzones
>> on the same nameserver) is not necessarily already being used for
>> bootstrapping.
>>
>> Example: Imagine a DNS operator which supports both DNSSEC and
>> bootstrapping.  They have a customer with the zone example.com and
>> a subzone foo.example.com, but DNSSEC is currently off.
>>
>> Suppose the customer turns on DNSSEC in the operator's service portal.
>> What will happen now is that the _boot zones under the operator's
>> nameserver hostnames will be populated with bootstrapping records for
>> these domains, with prefixes example.com._boot and
>> foo.example.com._boot.
> 
> I think in this case, you cannot start foo.example.com._boot. because
> its parental agent (which happens to be you too but should still follow
> the RFC) detects that the parent zone example.com is not signed and
> thus cannot perform a bootstrap of foo.example.com. Doing them at once
> would be a race condition. You'd really want to do these one after the
> other.
> 
>> Remember, the bootstrapping records are of type CDS/CDNSKEY, and they
>> will now show up both at the level of "foo.example.com._boot" and one
>> level up, at the level of "example.com._boot".
> 
> But can't you still publish all of these? like:
> 
> in dedyn.io zone (or ns1.dedyn.io zone or _boot.ns1.dedyn.io zoe):
> 
> example.<hash-of-example.com>._boot.ns1.dedyn.io IN CDNSKEY [...]
> foo.<hash-of-foo.example.com>._boot.ns1.dedyn.io IN CDNSKEY [...]
> 
> in your example.com zone:
> 
> example.com. IN CDNSKEY [...]
> 
> In your foo.example.com zone:
> 
> foo.example.com. IN CDNSKEY [...]
> 
>> As a result, the DNS operator is no longer free to make a delegation
>> at "example.com._boot", because that would change the meaning of the
>> bootstrapping records.  (CDS/CDNSKEY records have a conflicting meaning
>> when they occur at an apex.)
> 
> I still don't see the APEX problem?
> 
>> However, there's nothing wrong with enabling bootstrapping records
>> for both these domains at once.
> 
> I think there is. You can't boostrap a domain whose parent is not
> already fully DNSSEC enabled. As those parents are not valid candidates
> to take in CDS records.
> 
>>  There's no reason why DS records for
>> foo.example.com should not be put into example.com while
>> bootstrapping for example.com is running in parallel.
> 
> There is because the parent is unsigned and so whatever it is publishing
> about its children is lacking trust.
> 
>>  (It's not
>> even necessary for example.com to ever be securely delegated, if there
>> is another trust root for it, e.g. in an enterprise setting.)
> 
> There is. nothing under example.com will ever DNSSEC validate. It cannot
> make claims abouts its sub delegations via DS records as those DS
> records would be bogus.
> 
>> DS bootstrapping does not require the parent of the bootstrapped domain
>> to be secure.  The protocol should not concern itself with the chain of
>> trust above the domain that is being bootstrapped.
> 
> This intension was not clear to me from reading the draft. You want to
> DNSSEC bootstrap "islands of trust" ? I think that should be out of
> scope. You are then already in enterprise/provisioning territory where
> this provisioning can just be added without this new protocol.
> 
>> The protocol should not make any assumptions like that, so that
>> bootstrapping of several domains along the same branch in the DNS tree
>> (e.g. example.com, and foo.example.com) can be fully orthogonal.
> 
> I disagree. Sure you can have an island of trust, eg a manually
> configured trust anchor for internal.example.com with a DS trust anchor,
> but then you should still insist on all checks from internal.example.com
> to be securely delegated. So you first have to do foo.internal.example.com
> before you can do bar.foo.internal.example.com.
> 
> While I think this is true from a security and logical point of view, I
> think you will run into practical issues if you are attempting to
> retrieve or publish DS records that lack DNSSEC validation.
> 
>> 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.
> 
>> Adding such a delegation turns the corresponding name into an apex, and
>> thus requires that there are no bootstrapping CDS/CDNSKEY records at
>> that name, because they would silently change in meaning.
> 
> Ok, so I think you are saying that for:
> 
> example.com._boot.ns1.desec.io. IN CDS [..]
> 
> or
> 
> example.<hash-of-com>._boot.ns1.desec.io. IN CDS [..]
> 
> or
> 
> com._boot.ns1.desec.io. IN CDS [..]
> 
> That without the <hash> method, having a zone cut at
> com._boot.ns1.desec.io. could somehow change the meaning ?
> 
> You would have an NS and DS record for com._boot.ns1.desec.io., but
> not for example.com._boot.ns1.desec.io. where you would have a CDS
> or CDNSKEY. In fact, the lack of NS for example.com._boot.ns1.desec.io. means
> that you are not using CDS to update a DS.
> 
> I don't see the "silently change in meaning" ?
> 
>> The problem is that if we now put bootstrapping records at these
>> delegation points, they suddenly take on the meaning of conventional
>> (non-bootstrapping) CDS/CDNSKEY records for these subzones.
> 
> So for com._boot.ns1.desec.io. I dont see that happening, but I guess
> if you do both example.com._boot.ns1.desec.io. and
> foo.example.com._boot.ns1.desec.io, then you have:
> 
> com._boot.ns1.desec.io. IN NS ....
> com._boot.ns1.desec.io. IN DS ....
> example.com._boot.ns1.desec.io. IN CDS ....
> 
> If this last record is treated in the "regular" way, that means that example.com._boot.ns1.desec.io.
> is signaling to com._boot.ns1.desec.io to update its DS record. But
> there is no zone cut there, so the "traditional" meaning has no effect.
> 
> 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 don't think this issue is improved by using hashes.
> 
> Now let's say you want to use CDS for com._boot.ns1.desec.io. to notify boot.ns1.desec.io.
> 
> You would publish:
> 
> com._boot.ns1.desec.io. IN CDS ....
> 
> Now someone could think you are boosttrapping for com. Someone could
> fake the (unsigned) com NS records to be ns1.desec.io. And they could
> possible convince com's parent to do dnssec bootstrap. If the attacker
> manages to trigger the boostrap in com's parent, the parent would still
> find com is either A) already signed so only CDS in com directly can be
> used to update, not this bootstrap, or B) unsigned, in which case I
> again press my point that nothing under an unsinged delegation should
> qualify for booststrap anyway. Still the common non-attack case here
> would be that com has no nameserver ns2.desec.io so the bootstrap would
> be aborted. Meanwhile, your nameservers involved in the com._boot.ns1.desec.io.
> and _boot.ns1.desec.io zones can still use regular CDS updating,
> verifying the CDS/CDNSKEY is really in use for that domain and proceed
> with publication of the updated DS record.
> 
>>>>  Now let's consider bootstrapping for dedyn.io *itself* (not one of its
>>>>  children!).  The location of the bootstrapping records for this domain
>>>>  would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
>>>>  the *zone* which constains bootstrapping records for domains *under*
>>>>  dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io.
>>>
>>>  So as stated above, I don't think this is a valid use case, as you need
>>>  the bootstrap already in place ?
>>
>> You don't need that.
>>
>> You only need a validation path to exist for each NS hostname (and the
>> _boot zone underneath).
> 
> 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.
> 
>>>>  This has nothing to do with in-bailiwick.  The problem occurs because
>>>>  bootstrapping records cannot be at the apex (as to not overload the
>>>>  meaning of apex CDS/CDNSKEY records), but by "inheriting" the structure
>>>>  under dedyn.io, a situation arises where this condition is not met.
>>>>
>>>>  The solution is to not "inherit", but flatten the hierarchy, which is
>>>>  what the hash does.  With hashing, children of dedyn.io would have
>>>>  their bootstrapping records under h(dedyn.io)._boot.ns1.desec.io, such
>>>>  as example.h(dedyn.io)._boot.ns1.desec.io.
>>>
>>>  I would think you could still use exmaple.dedyn.io._boot.ns1.desec.io.
>>>  (regardless of hashing or not). But you need desec.io to already be DNSSEC
>>>  signed, and since you control desec.io, it should be trivial to add NS
>>>  and DS for _boot.dedyn.io, or TLD._boot.dedyn.io without needing to
>>>  bootstrap?
>>
>> I am not following.
> 
> the boostrap is usually needed to bridge the gap of Registrar and DNS
> Hoster. If the DNS hoster already has signed dnshoster.com, then they
> can just atomically create NS/DS records for _boot.ns1.dnshoster.com.
> They are not depending on another party that lacks the automation to
> deploy DNSSEC.
> 
>>>>  It is unclear to me how such situations would properly be dealt with if
>>>>  the bootstrapping owner names retained the target domains' hierarchy.
>>>
>>>  Can you explain why the above wouldn't work ?
>>
>> In the general case, there will be a collision between bootstrapping
>> records and conventional apex-level CDS/CDNSKEY records, unless
>> delegations within the _boot subtree are prohibited.
> 
> Yes :) But I hope I managed to point out you can still use CDS/DS within
> your bootstrap without the double meaning of the names outside the
> bootstrap chain.
> 
>>>>  One could of course specify that you can only ever bootstrap *one*
>>>>  name along a certain branch of the DNS tree.  But what would be the
>>>>  motivation for such a limitation?
>>>
>>>  No, you should be able to do all the domains you want, as long as you
>>>  prefix them into the _boot zone?
>>
>> Only if you enforce there are no delegations there, within the _boot
>> zone.
> 
> See above. I think you can.
> 
>>>>  I'm sure the situation could be complicated futher by considering more
>>>>  sophisticated delegation hierarchies (e.g. dedyn.io is at ns1.desec.io,
>>>>  foo.dedyn.io is not, but bar.foo.dedyn.io is again at ns1.desec.io, and
>>>>  so on).  These are all things the protocol should be ignorant of.
>>>
>>>  I don't think that needs to matter, you can even run NS/DS onto
>>>  _boot.ns1.dedyn.io with only ns1 as its nameserver and _boot.ns2.dedyn.io
>>>  with only ns2 as its nameserver?
>>
>> I am not following.
> 
> I was trying to say that I think these all work fine, with or without
> delegations in the FQDN path of the bootstrap names.
> 
>>>>  The hash ensures that *different things* get *different names*.
>>>
>>>  But the DNS is already pretty good at that with FQDNs?
>>
>> The DNS provides sufficient naming capabilities, yes.  My point is that
>> in your proposal, when dedyn.io and its children are hosted on the same
>> nameserver, two different things will turn up with the same name:
>>
>> 1.) the name of the bootstrapping records for dedyn.io
>> 2.) the name of the zone containing bootstrapping records for children
>>     of dedyn.io
>>
>> The name in question is: dedyn.io._boot.ns1.desec.io
>>
>> CDS/CDNSKEY records at that name can now mean two things:
>>
>> - They could mean "thing 1", i.e. bootstrapping records for dedyn.io
> 
> Yes.
> 
>> - They could mean "thing 2", that is DS rollover for the bootstrapping
>>   zone *itself* (dedyn.io._boot.ns1.desec.io)
> 
> No?
> 
> If your zone cut is at io._boot.ns1.desec.io or _boot.ns1.desec.io, then
> CDS dedyn.io._boot.ns1.desec.io does not have a traditional (C)DS record meaning,
> as there is no NS (zonecut) for dedyn.io._boot.ns1.desec.io.
> 
> If your zone cut is at dedyn.io._boot.ns1.desec.io because you have many
> delegations for <customers>.dedyn.io then the interpretation of CDS cannot
> be for boostrap because dedyn.io is already DNSSEC signed (or else you
> cannot / should not accept secure delegations for <customers>), so its
> intepretation is always for a classic DNSKEY roll signaling of the zone
> dedyn.io._boot.ns1.desec.io to its parent (either io._boot.ns1.desec.io
> or _boot.ns1.desec.io or ns1.desec.io or even desec.io). If you would
> try to mean it as this protocol and old software reads it as
> traditional, that software would abort too if it is unsigned. So I don't
> think you can accidentally break things either?
> 
>> It's not explicit what's meant, so there's an ambiguity.  Worse, if
>> you add or remove the delegation at dedyn.io_boot.ns1.desec.io, the
>> meaning of CDS/CDNSKEY records at that name silently changes.
> 
> But the meaning only changes from one invalid use to another invalid
> use?
> 
>> So, yes, the DNS is good at naming things differently, but we have to
>> create a naming scheme that is free of collisions.
> 
> I am not convinced. See above. I think it is clear based on where the
> (C)DS records are and who would even query for it at that particular
> location.
> 
> 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?
> 
> And regardless, you can create delegatations for com._boot just as
> easilly as <hash-of-com>._boot.
> 
> 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.
> 
> Paul
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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