Agreed. The question is whether a Signer knows of the existence of the other Signers before or after it generates keytags. Even if it could know of the existence of other Signers before it generates keytags, it seems to me a substantial additional coordination burden to have them sort out which one gets the high values and which one gets the low values. (And, of course, the multi-signer protocol does not limit the number of participating Signers to just two.)
But as I write this, I realize the keytag is generated using the key. Different Signers are *highly* likely to have different keys, so there's no need to create a salt. (It's been a *long* time since I looked at the algorithms.) Apologies. Steve On Wed, Jul 9, 2025 at 11:34 PM Mark Andrews <ma...@isc.org> wrote: > > > > On 10 Jul 2025, at 13:10, Steve Crocker <st...@shinkuro.com> wrote: > > > > I'm under the impression Signers will generally not know of the > existence of other Signers before they start generating keytags. Perhaps > each Signer should generate a salt that is likely to be independent of the > salt used in other Signers. > > > > Steve Crocker > > Signers may or may not have knowledge of other signers. Just because the > existing > signers weren’t developed with multiple signers in mind it doesn’t mean > that they > can’t be upgraded to know about multiple signers. For multi-signers to > work > DNSKEYs from each of the signers need to be distributed to the other > signers. The > mechanisms to do this are not specified in any RFC. > > > > > On Wed, Jul 9, 2025 at 11:05 PM Mark Andrews <ma...@isc.org> wrote: > > > > > > > On 10 Jul 2025, at 06:01, Peter Thomassen <peter= > 40desec...@dmarc.ietf.org> wrote: > > > > > > > > > > > > On 7/9/25 20:09, Jim Reid wrote: > > >>> Can you clarify source of your confidence about this 'not causing > issues'? > > >> Mental arithmetic. There are 2^16 possible key tags => there's a one > in 2^15 chance a new tag clashes with an existing one. > > > > > > Uniformity of the keytag distribution is a wrong assumption, see > https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf > > > > > > This deck also has some slides on impact. > > > > So just use a method that will work reasonable well with the generated > key tags. > > > > For two signers A uses 'tag < 32768' and B uses 'tag >= 32768’ as part > of the acceptance criteria > > when generating a new tag. > > > > Resolvers already do the bulk of the work with DNSSEC. A few more key > generation attempts on the > > authoritative side won’t hurt anything. > > > > > > > Have fun, > > > Peter > > > > > > _______________________________________________ > > > DNSOP mailing list -- dnsop@ietf.org > > > To unsubscribe send an email to dnsop-le...@ietf.org > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > _______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > > > > > > -- > > Sent by a Verified > > > > sender > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- Sent by a Verified sender
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
