Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
On 11/5/21 1:07 AM, Paul Wouters wrote: 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. I took a shot at that in -03. 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". Sure. The draft currently says in Section 3.2: | If the above steps succeed without error, the CDS/CDNSKEY records are | successfully validated, and the Parental Agent can proceed with the | publication of the DS record set under the precautions described in | [RFC8078], Section 5. ... and there, it says: | A parent SHOULD [...] ensure | that the zone validates correctly if the parent publishes the DS | record. A parent zone might also consider sending an email to its | contact addresses to give the child zone a warning that security will | be enabled after a certain amount of wait time -- thus allowing a | child administrator to cancel the request. I think that from a technical perspective, that covers the policy you're proposing. Or did you really mean to *impose* a minimum delay, as in: it is forbidden to deploy more quickly? Another approach would be to re-state explicitly what's in RFC 8078 Section 5 (but I don't know if text duplication between RFCs is welcome?). Best, Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
On Tue, 9 Nov 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. But would they hit 255 ? 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.). Per definition, you can create domain names that are too long to support _underscore labels on top of them. And yet there we did not use hashing either? I'd rather be conservative on exhausting the available length limits. There is something to be said for keeping thing simple too, and more human debuggable. Hashes don't make that easy. 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..If we do that, then we can't use bootstrapping for dedyn.io itself, because dedyn.io._boot. 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). You can't bootstrap in-baliwick anyway, can you? Also if your nameserver name is not in a zone protected by DNSSEC, you cannot use it in this scheme to deploy either I thought? - 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. You could simply use a different _label for the two cases. I did not like _boot anyway as it is too generic, so perhaps you could use _dnssec_bootstrap and _dnssec_hosted_bootstrap or something similar. - 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). ENT's aren't that great :P For example, with query minimalization on AWS Route53, these have been broken for years. I'd stay away from ENTs. - 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.) Yeah. Are there any conceptual downsides of the hashed label that would outweigh these points? Yes. Speaking of NSEC3, that is super hard for people to grasp. To us experts it is obvious, but all the hashes makes a new person who looks at it pretty confused. I think it would be good in general to try and make it so that operators can debug DNS issues with the dig command, without needing advanced tools. - _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 Thanks! - 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? I missed that. Perhaps it would be good to give it is own section. We all know now how bad TXT records at the APEX are now, and anything to repeat such a thing again would be good. - 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 Thanks. - 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). You
Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
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..If we do that, then we can't use bootstrapping for dedyn.io itself, because dedyn.io._boot. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
It appears that Paul Wouters said: >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 ? Probably not. There was also some thought that this makes it harder for tourists to guess the delegated zone names, not sure if anyone would care. >- I would like to see some text on removing the records too once the > child gained its DS record. That really needs to be about scaling issues. If your NS serves three zones and you leave in the _boot records, who cares. But there are NS that serve three million zones and I think we would all like to avoid long useless NSEC walks. >- Should it be explicitly noted that in-bailiwick domains are not > supported? Yes, I thought that was in there already. I did some counts in TLD files and found that in practice very few 2LDs use in-bailiwick NS. We should document it but it's not a big deal. >- 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) The point of this is to do a DNSSEC bootstrap that is fully DNSSEC validated. If the _boot record doesn't have to be signed, you might as well just use the CDS from the child server. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
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 ? - _boot seems too generic a name for this. _dsbootstrap would be better and cause less clashing - I would like to see some text on removing the records too once the child gained its DS record. - Should it be explicitly noted that in-bailiwick domains are not supported? - 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) 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". Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
Dear DNSOP and DNSSEC bootstrapping aficionados, 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. We requested a slot at IETF 112 to present the draft, and it would be great to have some discussions about it then. We'd also like to work towards adoption in the WG if there is interest. There are no technical changes from the previous version -01. Updates are exclusively on clarity, framing (as an RFC 8078 authentication method instead of a separate protocol), and otherwise editorial. Thanks, Peter Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt Date: Mon, 25 Oct 2021 16:56:41 -0700 From: internet-dra...@ietf.org To: Nils Wisiol , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-02.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-dnssec-bootstrapping Revision: 02 Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Document date: 2021-10-25 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.txt Status: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ Html: https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping Diff: https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-dnssec-bootstrapping-02 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]). [ 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 most recent version of the document, open issues, etc. should all be available there. The authors gratefully accept pull requests. ] The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
