Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-00.txt

[Peter Thomassen <[e-mail]>]

Dear DNSOP,

At IETF 112, it was discussed whether owner names of bootstrapping records should be
- "plain", e.g. example.co.uk._dsauth.ns1.desec.io, or
- "hashed", e.g. example.<hash(co.uk)>._dsauth.ns1.desec.io.

Most people favored the plain form for its simplicity, and subsequently the authors removed the hashing logic from the draft. As a consequence of that, an ambiguity in the protocol has been exposed.

This message documents the details of that problem and potential ways of addressing it, both for future reference, and in order to move towards consensus regarding its resolution.

I am going to lay out the problem from scratch (apologies for the very long message; I hope it's worth the read!), and will be labeling the various arguments etc., so that it's easy to refer to them during discussion and to point at where exactly there is disagreement.

I'll start out with some presumed goals (which I call propositions for the sake of discussion). I would have thought that there is consensus about these, but some previous messages suggest that there isn't (although the discussion was not concluded back then; https://mailarchive.ietf.org/arch/msg/dnsop/hSDaiSbhLszrlln_TNfM0iKXwmU/). Generally, it would be interesting to establish consensus on which of these propositions the group considers goals for the DNS, and which it doesn't (even independently of the bootstrapping protocol).


# Proposition P1:
DNS protocols should aim to work on all levels of the DNS. As far as the bootstrapping protocol is concerned, it should thus not be restricted to delegations in an (effective) TLD zone, but work for DNSSEC-bootstrapping arbitrary delegations (at least in principle; deployment is a different question).

Rationale:
Otherwise, custom solutions are needed on other levels, indefinitely. We should be aiming to design a protocol that works everywhere, to avoid the extra complexity/effort/cost/source-of-error/... from custom solutions (at least in the long term). -- I can only speak for deSEC, where we do have custom mechanisms for DNSSEC management of internal delegations. If CDS/CDNSKEY-based bootstrapping and rollovers were natively supported in authoritative servers, we would *certainly* favor that over our custom stuff, which we would quickly get rid of.

In addition, zone owners should not have to worry about what's going on with zones in other parts of the DNS tree; things should "just work" for their domain, without cross-dependencies (whenever possible).


# Proposition P2:
Customers of DNS operators should be able to create zones that are not delegated yet. This includes creating multiple zones where one is a subzone of the other.

Rationale:
This allows preparing zone contents before delegation, to avoid downtimes etc.


# Proposition P3:
Bootstrapping records should be made available before delegation.

Rationale:
This is important because the parent's policy may be that only secure delegations will be performed (= setting NS and DS at the same time). (To my knowledge, there is at least one ccTLD registry working toward such a policy; I hope this will occur more frequently in the future.)


# Proposition P4:
DNS operators should make no assumptions about the order in which customers will create/delegate their zones, and should enable them to do so in any order. In particular, when a zone is configured, the operator cannot assume that the customer will not want to configure/delegate an ancestor zone (parent, grandparent, ...) at some later point in time.

Rationale:
Often, the higher-level domain will be delegated first. However, this is not always the case. For example, at deSEC, we have repeatedly observed that a customer who owns example.org first creates test.example.org and delegates the domain to us; once testing is completed, the customer creates their main zone example.org, and delegates that one to us. In this case, the parent gets delegated to us after the child is.

Another example is if a university hosts their own DNS service for example.edu (with DNSSEC), but (e.g.) conference stuff lives under conferences.example.edu which is delegated to some other provider. If the university later decides to migrate their main zone to the same provider (meanwhile going insecure temporarily), the parent will be delegated to that provider, who should then be able to *re-bootstrap* the delegation -- even as they are already operating the child (whose DNSSEC configuration remains untouched). It will not be understandable to the owner of example.edu why bootstrapping of that domain should not work in this case.

The same thing can happen with IPv6 reverse zones, where one is for a subnet of the other. Another case could be when _acme-challenge is delegated to a provider that integrates nicely with Let's Encrypt clients, and the main zone is migrated there later. In all of these cases, the DNS operator cannot foresee the order in which their customer will perform the delegations. It would be very unexpected for the customer (and look like a bug) if DNSSEC bootstrapping worked for some orders, but not for others.

(NB: Rejecting P4 by prescribing an order implies rejecting P1 as well, as the protocol wouldn't work on all levels at all times.)


# Proposition P5:
It should be possible for a DNS operator to structure a bootstrapping zone by introducing additional zone cuts below the _dsauth label.

Rationale:
Besides moving bootstrapping records for a certain parent to a subzone, there are other plausible reasons for zone cuts in the bootstrapping zone, such as when parts of the bootstrapping domain should run on a different nameserver, or use a new DNSSEC algorithm. I wouldn't know why an operator would want to do that now, but here's something I made up: let's say a computationally expensive post-quantum scheme is introduced; perhaps the operator wants to use that only to bootstrap domains whose parent (TLD) has adopted the algorithm, and save the cost otherwise.

(Other situations affected by this may include NS whitelabeling situations (I have not fully considered the implications here), and perhaps other future scenarios that are hard to foresee.)

Whether these scenarios make sense or not, I have a hard time justifying that operators would *never* want to do that and *not* run into an undesirable situation if this is made impossible by design. It thus seems worthwhile to me to keep that door open.

Having said that, rejecting P5 would also break with the history of the DNS, where zone cuts have been admissible and transparent everywhere in the tree.


# Consequences:
 From propositions P1-P4, it follows that
C1. a DNS operator needs to allow a customer to create both test.example.org and example.org (regardless of whether they are delegated);
C2. the DNS operator needs to be able to provide bootstrapping records for both zones at the same time, at FQDNs like
	- test.example.org._dsauth.ns1.desec.io,
	- example.org._dsauth.ns1.desec.io;
C3. as a result, the DNS operator is not free to introduce a zone cut at example.org._dsauth.ns1.desec.io in the bootstrapping zone.

Conclusion C3 is in contradiction to proposition P5.

This is because bootstrapping records are of type CDS/CDNSKEY, which already have non-bootstrapping meaning when they occur at an apex (RFC 8078). It follows that a DNS operator cannot configure a zone cut within the bootstrapping zone (underneath the _dsauth level), because due to P4, they cannot assume that a customer would not create a zone which would require conflicting bootstrapping records at that same owner name. As a result, the bootstrapping records all have to live in one monolithic zone.

(If such a zone cut was done at, say, example.org._dsauth.ns1.desec.io, the CDS/CDNSKEY records at that name would turn on-apex, and as such would signal the key parameters for the "example.org._dsauth.ns1.desec.io" subzone and not the bootstrapping records for "example.org". This is the heart of the problem at hand.)


# Discussion
One can only accommodate the consequence C3 by asserting that structuring of a bootstrapping zone into subzones (in particular, by parental suffix) is not up to the DNS operator: zone cuts below _dsauth are effectively prohibited due to the semantic collision that otherwise arises. This is a (perhaps unexpected) departure from the tradtional way of things, in which zone cuts are pretty much orthogonal to anything else. The existence of zone cuts so far had no bearing on the semantics of zone data (ignoring cut-related records like NS and SOA). If such a restriction is desired, it should be explicitly specified as that.

Depending on which propositions one shares, one may dispute that there may be a problem in practice. But even then, as the ambiguity is known, the draft should address it one way or the other.

The following are the different solution approaches of which I am aware:


# Solution S1: Use a different record type, e.g. BDS/BDNSKEY ("bootstrapping DS/DNSKEY").

If this is done, the collision is removed completely. It requires more implementation work in DNS software (support by auth servers, client tools and libraries like dig/dnspython, etc.), but it is very clean.


# Solution S2: Use a hashed naming scheme to avoid the collision.

Contrary to intuition, this *is* practical to combine this with synthesis of bootstrapping responses (see below).

Mechanism: Fold all labels of the customer domain into a hash, except the first. With example.org and test.example.org, we would have the following bootstrapping names:
- example.<hash(org)>._dsauth.ns1.desec.io
- test.<hash(example.org)>._dsauth.ns1.desec.io

Bootstrapping records would always be at the leftmost level (off-apex), and zone cuts by parent suffix can be made at the second level from the left (and their CDS/CDNSKEY records can be used for RFC 8078 rollovers etc. as usual, without a collision).

Answering a query dynamically (with synthesis) requires reversing the hash, which means that a mapping needs to be stored. Note, however, that the mapping would *not* contain *each domain*, it would only contain *each immediate ancestor*. Typically, that would mean that the mapping would primarily contain *one entry per public suffix* used at the provider, changing only rarely.

The mapping could be stored via PTR records at the hashed label itself, e.g. <hash(co.uk)>._dsauth.ns1.desec.io IN PTR co.uk. This can be done at zone creation (or loading) time: when encountering example.co.uk, you would create this PTR record. Answering a query for example.<hash(co.uk)>._dsauth then requires an internal look-up of the PTR record at the hashed label, whose target is then appended to the first label of the query to construct the customer domain. This does not require any additional inverse search algorithms or reverse-indexed datastructures.

It also maximizes the applicability of the protocol to unusally long domain names (both in byte count and in number of labels) due to the fixed hash digest length.

A major downside is that to investigate bootstrapping records, administrators would have to deal with these hashes, at least as long as tools like dig wouldn't have built-in support.


# Solution S3: Allow bootstrapping only using the leaf domain under _dsauth.

If only the lowest level may be used for bootstrapping (and higher intermediate levels may not), one can put zone cuts at higher levels in the bootstrapping zone, with CDS/CDNSKEY records reserved for managing DNSSEC at the zone cut.

This approach violates P1, because the domain whose bootstrapping records would live at the zone cut can no longer be bootstrapped. Further, it violates P4, because bootstrapping would only work "in order" (from higher to lower level domains). This would mean that a customer who creates test.example.org for testing, and only later creates and delegates example.org, will be subject to silent failure of DNSSEC bootstrapping for their main domain. That is rather unexpected.

(Alternatively, DNS operators could prevent customers from creating the higher level zone (example.org) when a lower-level zone exists, so at least DNSSEC won't fail open silently. Additional logic / complexity / implementation requirements apart, this would violate P2.)

When taking this route, more complications arise: Should bootstrapping records be restricted to leaf names even if there is no zone cut above?
--> If yes, that violates P1 more strongly than necessary (that is, regardless of whether a zone cut would actually get in the way or not).
--> If no, then someone trying to make sense of CDS/CDNSKEY records at "example.org._dsauth.ns1.desec.io" would need to be aware of whether there is a zone cut, as the records' interpretation depends on it (bootstrapping records for "example.org" vs. RFC 8078-style rollover records for "example.org._dsauth.ns1.desec.io"). -- However, a client has no easy way of knowing this, nor should it have to implement [or remember to run, in case of an admin chasing a problem] complicated logic to figure out what the semantics are. (Besides, any such logic would be subject to race conditions, because the DNS is only eventually consistent.)


# Solution S4: Disallow CDS/CDNSKEY usage for DNSSEC management of subzones under _dsauth ("bootstrapping has precedence").

This reserves CDS/CDNSKEY records anywhere under _dsauth for bootstrapping. If there is a zone cut, manual key management for it is required.

The price of this is to restrict the scope of on-apex CDS/CDNSKEY records, by making it illegal for them to appear below a _dsauth label. Issues in auth and library bug trackers would follow, discussing whether their input validation should catch such cases because no illegal data should be accepted, etc. People who have nothing to do with DNSSEC bootstrapping (e.g. dnspython maintainers) would be dragged into that stuff suddenly coming their way.

As a result, RFC 8078 key rollovers for subzones like "example.org._dsauth.ns1.desec.io" would be broken -- for no good reason except that a solution with less side effects was not found. It feels like a kludge to me and not like a sound technical solution.

In addition, P1 is violated, because the bootstrapping protocol wouldn't work to bootstrap subzones under _dsauth themselves.


# Solution S5: Disallow zone cuts under a _dsauth domain entirely.

In this case, all CDS/CDNSKEY records under a _dsauth domain are off-apex. The situation is effectively equivalent to S4, except that zone cuts would be forbidden (instead of requiring manual key management).

The proposal is simpler than S4 and does not require re-defining on-apex CDS/CDNSKEY semantics, but is also more restrictive. It codifies the departure from the previous custom that zone cuts could occur anywhere, violating P5.


# What now?
Solutions S3-S5 violate one or more of P1-P5, and/or break an existing standard (RFC 8078) to some extent. I feel rather uneasy with that kind of "roadkill". For one, this is because the restrictions they introduce seem unnecessary to me: I'm not convinced that we need to compromise on the goals set out by P1-P5. I think we can do better.

Perhaps more importantly, I feel that S3-S5 intertwine different aspects of the DNS world that should not get entangled (e.g.: S4 touches the on-apex CDS/CDNSKEY specs although that should be orthogonal to off-apex use for bootstrapping; S3 introduces timing dependencies between zones and enforces related policies on DNS operators).

In order to minimize future headache, I think it is important to aim at minimal dependencies between components of the DNS, and we should strive for maximum orthogonality. (See also: "Orthogonality of features", https://blog.apnic.net/2018/03/29/the-dns-camel/)

S1 and S2 seem to approach the problem closer to its root cause: we have a (name, type) ambiguity, so the most "honest" solution would be to fix either the owner name (S2) or the record type (S1). Of course, these ideas have their disadvantages, too.

In any case: the current draft has nothing to say about the ambiguity problem, so it needs to be addressed one way or the other.

What does the WG think?

Best,
Peter


On 4/22/22 06:29, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>          Title           : Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator
>          Authors         : Peter Thomassen
>                            Nils Wisiol
> 	Filename        : draft-ietf-dnsop-dnssec-bootstrapping-00.txt
> 	Pages           : 14
> 	Date            : 2022-04-21
> 
> Abstract:
>     This document introduces an in-band method for DNS operators to
>     publish arbitrary information about the zones they are authoritative
>     for, in an authenticated fashion and on a per-zone basis.  The
>     mechanism allows managed DNS operators to securely announce DNSSEC
>     key parameters for zones under their management, including for zones
>     that are not currently securely delegated.
> 
>     Whenever DS records are absent for a zone's delegation, this signal
>     enables the parent's registry or registrar to cryptographically
>     validate the CDS/CDNSKEY records found at the child's apex.  The
>     parent can then provision DS records for the delegation without
>     resorting to out-of-band validation or weaker types of cross-checks
>     such as "Accept after Delay" ([RFC8078]).
> 
>     This document updates [RFC8078] and replaces its Section 3 with
>     Section 3.2 of this document.
> 
>     [ Ed note: Text inside square brackets ([]) is additional background
>     information, answers to frequently asked questions, general musings,
>     etc.  They will be removed before publication.  This document is
>     being collaborated on at https://github.com/desec-io/draft-thomassen-
>     dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-
>     thomassen-dnsop-dnssec-bootstrapping/).  The authors gratefully
>     accept pull requests. ]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-00.html
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> 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