> And how is this different to migrating to IDKEY? The validator > would need to support DS + IDDS + DNSKEY + IDKEY for a significant > period. One can turn off support for algorithms without the new > semantics. As for *SHA-1 many validators already treat those > algorithms as unsupported.
I'm not here to defend IDKEY. As far as I know that is not even a draft. What I'm saying is that we should avoid creating additional DNS protocol code points to deal with collisions. > > 2) Some operators expressed concerns about prohibiting colliding keys, > > especially in multi-signer setups. Delaying the deprecation of current > > algorithms. > > There are several easy ways to address this. IDKEY would require > this to be addressed. Nothing different here. Again I'm not defending IDKEY. Avoiding collisions was discussed earlier this year. As far as I remember there was no consensus among the signing community to have hard requirements against collisions. I don't know if anything has changed in the mean time. But that seems a good place to start. > > 3) My own analysis shows that for reasonable zones there is no need to > > tolerate more than 1 signature verification failure per RRset. So > > the gains are no all that high. > > One failure is one too many. IDKEY and this are about removing > the need to have to process duplicate key ids when validating. > > We have done stuff like this before with the introduction of NSEC3. > It is achievable. NSEC3 was actually desired by people with secure zones. I don't see any desire in that community to avoid collisions. And the gains are just not there. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
