And if the DS hash is not in the DNSKEY set you don’t know whether to treat the delegation as secure or insecure as you don’t have the necessary information. The only safe thing to do is to treat it as insecure so you better get you DNSKEY / DS management correct.
> On 28 Mar 2025, at 07:38, Mark Andrews <ma...@isc.org> wrote: > > It’s not to hard to implement. We just see impatience about it not being > already implemented. The hard part is DS record hashes don’t include the OID > or the name like DNSKEY and RRSIG do. This is a bug in the specification of > DS. The DNSSEC algorithm specification is incomplete. If the testers are > willing to use DS aliases and not the currently assigned DS algorithms this > is easily addressed by including the OID/name at the start of the DS hash > field. Otherwise one has to fetch the DNSKEY RRset, match the hash to work > out which private type algorithm one is talking about in the DS. > > Everything else is straight forward. > -- > Mark Andrews > >> On 28 Mar 2025, at 03:51, Paul Hoffman <paul.hoff...@icann.org> wrote: >> >> On Mar 27, 2025, at 08:56, Petr Špaček <pspa...@isc.org> wrote: >>> >>>> On 3/21/25 12:41, Paul Hoffman wrote: >>>> On Mar 21, 2025, at 15:40, Paul Wouters <p...@nohats.ca> wrote: >>>>> This is a one octet registry. This specific registry was mentioned by me >>>>> a few times as one of the problem ones where a very lose registration >>>>> policy mifgt not well suited for allocation for early drafts or code >>>>> points. >>>>> >>>>> DNS itself also has a very long tail (decade) so in the past, algorithms >>>>> have been controlled fairly strictly to avoid large amounts of mostly >>>>> dead code. >>>>> >>>>> It might make sense to instead update the registry to allocate 5 private >>>>> use code points and use those for the various experiments. >>>> The registry has over 200 unused code points. Even if we assume that a >>>> massive signature comparison effort happens every 20 years, we can easily >>>> afford to burn 20 per effort. RFC 6014 hinted at this. >>> >>> Well maybe. But there are also proposals to partially use algo-number as a >>> bit-field - e.g. for DRY RUN DNSSEC protocol extension. >> >> Which do you feel is more important: testing lots of new signature >> algorithms, or dry run as is initially proposed? >> >>> See below for more flexible approach. >>> >>>> Please remember that, if we get anywhere close to running out of code >>>> points in this registry, it is trivial to extend the registry. 100 years >>>> from now, when we are all dead, someone can define a new signature >>>> algorithm whose first two bytes of the digest are codepoints in another >>>> registry that has a more sensible length than what we gave to this one. >>>> I propose that someone who is already working on testing many algorithms >>>> (such as Ondřej) create a short Internet Draft that is little more than a >>>> table whose columns are: >>>> - algorithm name >>>> - a number starting at 50 >>>> - stable reference to the algorithm >>>> Those interested in PQC algorithms bounce that draft around on the >>>> pq-dns...@ietf.org mailing list (not here on DNSOP) for a few months, then >>>> ask the ISE to publish it. Any algorithm that did not make the list in the >>>> draft can write its own draft for later RFC publication. >>> >>> FTR there's also possibility to use OID and DNS names as algorithm >>> identifier. See algo numbers 253, 254, RFC 4034 appendix A.1.1. >> >> Every time this mechanism comes up, it is dismissed as being too hard to >> implement. >> >>> It would be nice if we exercised this extensibility as it gives us >>> practically unlimited space. >> >> When we have fewer available, maybe. But for now, we have a huge number >> available and a real need to do research on which signature algorithms will >> be best for us. I propose that we use the code points the way they were >> supposed to be used: in the protocol. >> >> --Paul Hoffman >> >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org > > _______________________________________________ > 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
