Hi, > On 25 Oct 2023, at 17:50, Joe Abley <[email protected]> wrote: > > On 25 Oct 2023, at 17:31, Johan Stenstam > <[email protected]> wrote: > >> On 25 Oct 2023, at 11:32, Joe Abley <[email protected]> wrote: >> >>> I am not at all familiar with SIG(0), so bear with me. What is the key >>> distribution mechanism for the DNS UPDATE originator's public key? RFC 2931 >>> suggests an unsigned KEY RR, I think? >> >> My answer is “whatever mechanism the child and parent is using today for >> communicating critical information like that”. > > Isn't the usual answer to that the same kind of ad-hoc, manual mechanisms you > are trying to avoid?
The difference is that if we set this up once (i.e. the public SIG(0) key is available to the parent) then we’re done. The same logic in the child primary that today cause it to publish a CDS or a CSYNC record could be trivially extended to issue a dynamic update that is sent to the parent. So, yes, to go from a system that is manual today to something that is fully automated tomorrow it is necessary to make one more, hopefully final, manual operation. I think that’s almost universally true. >> The problem I have with that is that this leaves out major parts of the >> namespace. I.e. I want a mechanism that works for the University of Foobar >> to automate the delegation information for a ~100 departments. > > I understand the desire for automation. > > I'm not sure I understand the part where automation is predicated on a manual > exchange of a token. If manual exchange is an option, why not just manually > exchange the DS RDATA? Se above. It’s only a bootstrapping process. > I'm also not sure I understand why bending the DNS into providing an > authenticated API to signal between the system signing the child zone and the > system producing the parent zone is better than building one using more > conventional techniques like TLS, HTTP, REST, etc. That’s a fair argument. We’ve had the same argument around the generalised notifications draft. My answer is that for the case where the parent is a well-resourced and clueful registry we could do this in essentially any of several ways. But I want to make this viable also for the smaller, less DNS-focused parents. And for that reason I want to minimise complexity. If complexity wasn’t an issue, well, then every parent could run CDS and CSYNC scanners and we would all be happy. I wonder why that isn’t happening. But for these smaller parents that don’t have DNS as their core interest, well they already have a primary name server. I think that in a non trivial number of cases the best alternative may actually be the child running something like BIND 9.28, which issues DDNS updates when it detects that delegation stuff has changed and the parent runs perhaps BIND 9.25, which is able to receive and process those updates and automatically update the child delegation in the parent zone. Oh, wait, mea culpa, that should be BIND 9.14-ish (or something). Guess what, we’ve already had this exact functionality for many years. If you run BIND-something at home you already have this and there is zero new complexity, zero new services to run, zero new code to write and debug. It’s already there! I don’t know if you’ve read the entire draft or not, but the key issue with the draft is not using DDNS for updating delegation information, we’ve had that for many years. The key issue is how to figure out where to SEND the DDNS update (and there I borrow the exact same mechanism that we use for generalised notifications). > Lastly, I'm not sure why people want to roll non-compromised keys anyway, or > under what circumstances it's ok to trust a compromised system to automate a > key replacement under those circumstances. I mean, there surely are some, but > this feels like a difficult thing to match to a general solution. I agree. But it is bad to design a system where the key CANNOT be rolled. And in this case, once bootstrapped, the key can be rolled, if the child so chooses. Regards, Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
