Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Peter Thomassen <[e-mail]>]

For the record, Paul and I sorted these out off-list (for real, this time!), and I'll push a new revision of the draft shortly.

~Peter

On 11/20/23 16:49, Peter Thomassen wrote:
> Hi Paul,  (off-list)
> 
> To keep the ball rolling, may I nudge you for your opinion on the below? :)
> 
> Thank you very much for your input,
> Peter
> 
> 
> On 11/13/23 22:30, Peter Thomassen wrote:
>> Hi Paul,
>>
>> Thanks for your thoughts. I'd like to address your points below and would very much appreciate your follow-up response.
>>
>> On 11/11/23 12:55, Paul Wouters wrote:
>>> I have read the document and I am supportive of the idea, but I find the
>>> document not ready. Some issues I have with the document in the current form:
>>>
>>> - It "deprecates" RFC8078 but does not offer a solution for all cases of
>>>    8078, such as when all nameservers are in-domain of the child.
>>
>> That is correct. This deprecation was requested to be clarified (but not challenged) in the Dnsdir review [1].
>>
>> During the subsequent considerations on the list, nobody objected, which I read as "the WG prefers deprecation".
>>
>> If the WG feels differently, let's change the text. Perhaps one or two people could speak up if they would prefer such a change.
>>
>> The question at hand is whether, given the cryptographically secure method of this document, we want to continue endorsing an insecure method, even if only for in-domain nameservers.
>>
>> I can imagine three kinds of things to say in the draft without continuing to endorse insecure bootstrapping:
>>
>> 1.) discourage the insecure method (by deprecating it);
>> 2.) perhaps even discourage in-domain nameservers;
>> 3.) perhaps point out that one might perform DNSSEC bootstrapping with at least one out-of-domain nameserver, then switch to in-domain nameservers (e.g., via CSYNC).
>>
>> The draft currently does the first thing, but not the other two.
>>
>> In-domain nameservers cause a bunch of problems (including the orphaned glue saga), and are also foreseen to be incompatible with DELEG-style delegations in ServiceMode [2].
>>
>> Reserving any judgment on the DELEG mechanism itself, it appears to me that in-domain nameservers are best advised against. So perhaps what we should do is (1) + (2).
>>
>> [1]: https://mailarchive.ietf.org/arch/msg/dnsop/04LYtemBnRjOBLWzgdD6RuaD5UU/
>> [2]: https://mailarchive.ietf.org/arch/msg/dnsop/rUY8CJHrrZYa0Sdvi3BV10IsfiE/
>>
>>> - Section 4.3 is named "Triggers" but it basically only describes
>>>    "Timers". Some of us have significant scar tissue on this matter,
>>>    and I don't see new information or a new technology here that
>>>    resolves this old discussion. It feels a lot like restating RFC8078.
>>
>> The situation in this draft is different from the trigger conditions in in Section 6.1 of RFC 7344 (which I think is what you meant). That RFC lists conditions for *updating* a DS RRset. This one here is for *initializing*, so other scenarios apply.
>>
>> For example, one condition listed here (but not in RFC 7344) for triggering the CDS authentication procedure is when the parent receives a new or updated NS record set for a child.
>>
>> Besides scans (which of course have a timer) and the receipt of a new NS RRset (which doesn't), the draft also mentions walking a list of children known to be in need of bootstrapping, perhaps received by AXFR or extracted via NSEC walk of signaling zones (and the NS receipt). I don't see any relation to timers here.
>>
>>
>> However, this is second instance (after [3]) that someone suggests to remove this section, so perhaps it's time to do so. Before doing so, I'd like to point out the following:
>>
>> The main takeaway from Section 4.3 is that the authentication mechanism requires reliable knowledge of the delegation's NS records, which -- depending on the trigger method -- may or may not be implicit in the trigger condition; as a result, a cross-check in the parent's database may be needed for certain triggers. This point is not contained in RFC 7344 (which deals with updates which use the child's existing chain of trust, so this point doesn't apply).
>>
>> In particular, scanning the registry database or installing a new NS RRset gives *certain* knowledge of what the NS records are, because the trigger conditions directly derive from processing an NS RRset that has previously been accepted for delegation.
>>
>> In contrast, when processing some kind of list fetched externally (e.g. walking the signaling domain _signal.$NS), it's possible to encounter signaling records pertaining to domains that are *not* delegated to $NS; therefore, the parent has to check that what's found in the list matches an actual delegation.
>>
>> I would like to hear your opinion on whether this point warrants the existence of Section 4.3; if it doesn't, I'll go ahead and remove it.
>>
>> [3]: https://mailarchive.ietf.org/arch/msg/dnsop/toP-e7Rc-ZLg0dR2SvzC25kAGxk/
>>
>>> - Style: I think the document is a lot more verbose and repetitive than
>>>    it needs to be. Condensing this would increase clarity of the
>>>    document.
>>
>> It looks like opinions within the WG differ here: the only other two feedbacks on style asked for more examples and otherwise described it as "very clear" (both from Secdir, [4]), and suggested to be more verbose by adding full RRset examples [5].
>>
>> I'll be happy to make adjustments, but I'm uncertain about what to change without "making it worse" from the perspective of others. Would you be able to suggest specifically which paragraphs/sentences you would like to be removed/condensed?
>>
>> [4]: https://mailarchive.ietf.org/arch/msg/dnsop/rIHtAMZ7erJ2Pc0NIAG1V6hlSrM/
>> [5]: https://mailarchive.ietf.org/arch/msg/dnsop/nBsMo1nENZzgUWd7-42zzAuM76w/
>>
>>> - There is the non-RRR model flavour of this and the RRR-model flavour.
>>>    What the parent can do greatly depends on the flavour and I think the
>>>    document instead focused on only using something that works with either
>>>    flavour.
>>
>> The document is fully agnostic of RRR considerations, and instead focuses on adding an authentication mechanism for RFC 8078, which also is agnostic of RRR considerations. (That's why the term "parental agent" is used.)
>>
>> Of course, when considering other options for delegation maintenance, a registry could do different things than a registrar; but to my understanding these are out of scope for RFC 8078 and, by extension, for this authentication mechanism. Given that, I'm not sure what your comment is trying to say?
>>
>>> - It seems WHOIS/RDAP could be better integrated for relaying a secure
>>>    signal instead of relying on insecure DNS lookups with the RRR-flavour.
>>>    For example, advising parents with delegation information (eg TLDs) to
>>>    lookup NS records in their own WHOIS/RDAP databse instead of using DNS
>>>    queries.
>>
>> The draft does not rely on insecure DNS lookups. Instead, parents directly use the knowledge they have as a parent, namely, the NS hostnames present in the delegation. (This point is emphasized in Section 4.3 which is also discussed above.)
>>
>>> - There are issues with very long domain names not fitting in the
>>>    current signal. Why not use hashed FQDNs as part of the signal part.
>>>    Additionally this might have some privacy and security advantages too.
>>>    (including friendlier to query minimalization :-)
>>
>> I completely agree with that. In fact, for precisely these reasons, hashing (of all labels but the first) was part of earlier incarnations of the draft, but, after discussions [6][7] around IETF 112, it was removed in draft-thomassen-dnsop-dnssec-bootstrapping-03.
>>
>> (The WG had settled on the plain variant mainly to ease debugging by visual inspection without additional tooling. Hashing also poses a challenge for synthesis of signaling records, which requires reversing the hash. That might be doable if only the parent name is hashed, see [6].)
>>
>> [6]: Slide 11 of https://datatracker.ietf.org/meeting/112/materials/slides-112-dnsop-sessb-automatic-bootstrapping-of-dnssec-delegations-00
>> [7]: https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/
>>
>>> - I find Section 4.1 and 4.2 and the Security Considerations a bit of
>>>    of a weird split. A bullet list of things to do is specified but
>>>    then additional things are specified in the Security Considerations.
>>
>> I agree that Security Considerations are not the place for specification.
>>
>> There's only one uppercase keyword there, namely that it's RECOMMENDED to diversify a delegation's NS hostnames across several TLDs, for security reasons. As this doesn't pertain to the authentication protocol of Section 4 itself, I felt that's OK. But sure, let's move it upstairs! :-)
>>
>> So, how do you feel about the following?
>>
>> At the end of 4.1, add:
>>
>> NEW
>>     To avoid relying on the benevolence of a single Signaling Domain
>>     parent (such as the corresponding TLD registry), it is RECOMMENDED to
>>     diversify the pathfrom the root to each nameserver.  This is best
>>     achieved by usingdifferent and independently operated TLDs for each
>>     one.
>>
>> ... and replace the last paragraph of the Security Considerations with the following two:
>>
>> NEW
>>     In any case, as the Child DNS Operator has authoritative knowledge of
>>     the Child's CDS/CDNSKEY records, it can readily detect fraudulent
>>     provisioning of DS records.
>>
>>     In order to prevent the TLD of nameserver hostnames from becoming a
>>     single point of failure in a delegation (both in terms of resolution
>>     availability and for the trust model of this protocol), itis
>>     advisable to use NS hostnames that are independent from each other
>>     with respect to their TLD.
>>
>>> - The "_signal" name is very generic. It would be clearer to use a more
>>>    descriptive name that also has less chance of being used by completely
>>>    different technologies.
>>
>> The structure of the signaling name was discussed at the DNSOP Interim in May 2022 [8]. To avoid limiting operators' freedom to introduce zone cuts at arbitrary points in the tree, the WG settled on using a structure that includes a descriptive prefix label as well as a generic intermediate label. Details on rejected alternatives can be found in [7].
>>
>> Keeping the intermediate label generic comes with the side effect that new operator signals (such as multi-signer key exchange [9]) can be easily introduced via a new prefix, avoiding the need for a new entry in the "underscored names registry" each time. -- The draft reserves the "_signal" label for use such operator-side signaling, to prevent collision with other technologies.
>>
>> [8]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa-authenticated-dnssec-bootstrapping-00.pdf
>> [9]: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-mske/
>>
>>> I think the goal of the document is to further widepsread automated
>>> deployment of DNSSEC. This happens by the bigger DNS hosters, mostly
>>> for delegations under a TLD.
>>
>> It may also happen by smallrt DNS hosters, in case implementations are added in common authoritative server software.
>>
>> The IETF 114 hackathon has produced a LUA implementation for PowerDNS (used at deSEC), and the RIPE 86 hackathon worked on a native implementation for Knot DNS. We're planning to finish this as part of a project funded by NLnet [10].
>>
>> [10]: https://nlnet.nl/project/AuthenticatedDNSSECbootstrap/
>>
>>> I think it best to limit the solution to
>>> this space,
>>
>> For what reason? -- Those preferring other solutions may certainly use them, but I don't see why that should imply a restriction on the applicability of any specific one.
>>
>>> and not try to fold in supporting other cases. Enterprise
>>> deployments can use CDS/CDNSKEY with hooks in IXFR/AXFR detecting these
>>> records automatically.
>>
>> I'm not sure what you mean here.
>>
>>> All in-domain nameservers are people who registered
>>> their own stuff and are running their own nameservers.
>>
>> That's not correct; we have a bunch of users on our managed DNS hosting platform who insist on creating vanity nameserver names under their domains. We'd like to stop them (so that it's easier for us to renumber our NS), but it seems we can't really.
>>
>>> The main use case is non-technical people getting a domain with DNS/web
>>> hosting, where the DNS hoster uses DNSSEC and would like to tell the TLD
>>> to enable DNSSEC. If the Hoster is the Registrar, there is no problem.
>>> It should be able to use EPP to get a DS into the Registry. If the
>>> DNS hoster is not the Registrar, then this EPP path is not available.
>>> But usually those DNS hosters _are_ Registrars already, but only for their
>>> own zones and their customers zone. Just this customer is using their
>>> DNS service but not their registrar service. Place the information there,
>>> eg via EPP. This would be much more secure than DNS timers/triggers.
>>
>> I agree with parts of that and don't with other parts; but I think it's a tangent. The draft doesn't tell everyone to use the protocol, and certainly not internally within a registrar that's also the operator.
>>
>> What the draft does is taking the existing method of RFC 8078 and adding authentication. I assume we're generally in agreement that that is a good thing (please correct me in case you disagree). The use cases are the same use cases as for RFC 8078, and the draft isn't touching that.
>>
>>> If this is truly too complicated (which I think it should not be), DNS
>>> signals could be used, but I would simplify it by telling the customer
>>> that for moving the domain to the new DNS hoster, to add a special NS
>>> record that indicates the DNSSEC information, eg:
>>>
>>> customer.example IN NS ns0.dnshoster.tld.
>>> customer.example IN NS ns1.dnshoster.tld.
>>> customer.example IN NS <hash of DNSKEY>._cds.dnshoster.tld.
>>>
>>> The DNS hoster can confirm they are the hoster by simply putting a
>>> (signed) A/AAAA record at <hash of DNSKEY>._cds.dnshoster.tld. using one
>>> of the real nameserver IPs as RDATA. This prevents people from
>>> adding the DNS hoster without permission.
>>
>> Preventing illegitimate use of nameservers ("lame delegations") is an entirely different protocol. The draft is trying to authenticate DS records.
>>
>> 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