The below isn't really a response to Jim's review, but rather a (somewhat opinionated) extension to it.
On 3/17/25 21:41, Jim Reid via Datatracker wrote:
12) It would be helpful to explain what sort of configuration details are not part of the zone data.
This refers to In the decentralized models all signers will communicate with each other and execute the necessary steps on their instance only. For this signers need a specialized protocol to communicate configuration details that are not part of the zone data. It's not clear whether it will really be out side of zone data: - Internetstiftelsen's draft https://datatracker.ietf.org/doc/draft-leon-distributed-multi-signer/ holds this configuration inside the child zone, and so far looks like the most developed approach. - Alternative approach https://www.ietf.org/archive/id/draft-thomassen-dnsop-mske-00.html has it in the nameserver hostnames' zones (also zone data, although not the child's). In short, it seems premature for the draft to make this statement. I'm not sure what would be safe to say about those models without making either a trivial or a speculative statement.
29) Opening para of Section 6 is clunky. How about "To ensure consistent behaviour by validating resolvers, all signers in a multi-signer group MUST use the same algorithm(s) to ensure consistent behaviour by validating resolvers"?
[...]
31) Section 6 seems to contradict itself. It starts off saying signers need to use the same algorithm and then says they don't. I'm confused.
It says that signing with different algorithms is not allowed by current specs, but validators accept it in practice. My view is that if we insist on "different signers MUST NOT use different algorithms", we'll break multi-signer's neck because it would imply 1. that all signers perform algorithm rollovers at the same time (but why would, e.g., Cloudflare want to coordinate a hypothetical migration from algorithm 13 to 15 with NS1?); 2. that a signer would not be able to introduce an experimental algorithm (e.g., PQC when ready); 3. that a secure change from one provider with an old algorithm (e.g., algorithm 8) to a provider with a modern algorithm would be illegal. I believe that protocol development around multi-signer should primarily tackle *this* problem. (The other aspects about how to get each other's keys in sync and how to know when it's safe to take the next step (timing) are also relevant, but those are not DNS protocol problems. They also partly depend on how the multi-algo issue is addressed.) Until that is addressed, I think it may also be premature for this draft to reinforce a MUST NOT that multi-signer users in practice would like to see changed (and that we know is not followed in practice, because violating it works). For a solution proposal, see https://www.ietf.org/archive/id/draft-huque-dnsop-multi-alg-rules-04.html. tl;dr: I'm wondering if this draft perhaps should wait until the multi-algo issue is solved and until more experience with (de)centralized models has been gathered. My 2ct, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
