BIND currently treats 253 as unknown > On 22 Mar 2022, at 19:56, Nils Wisiol <[email protected]> wrote: > > There was some internal discussion about using 17 vs 253, with the main > argument for 253 being that this is the intended use case for 253 and > the main argument for 17 being that worry that some resolver > implementations could have special treatment for private algorithm > numbers. As we are interested in how FALCON-512 would behave in the > existing DNSSEC infrastructure, I pushed for using 17. I have to admit > though that I did not do research whether there exists special > treatment for private algorithms. > > To settle this, I would like to ask the resolver vendors on this list: > is your treatment of private DNSSEC algorithms (253) any different from > unknown algorithms (such as 17)? > > In any event, we shall make our implementation flexible wrt to the used > algorithm number(s). The intent was explicitly not to make any claims > on unused numbers. > > Best, > Nils > > On Mon, 2022-03-21 at 19:32 +0000, Paul Hoffman wrote: >> On Mar 21, 2022, at 11:34 AM, Wessels, Duane < >> [email protected]> wrote: >>> Is it in response to the DNS-OARC talk we saw about implementing >>> PQC Falcon in PowerDNS, and they used the next unused algorithm >>> number rather than a private algorithm? >> >> Nils could have picked 253 but probably didn't even think of looking >> down to the bottom of the list. He was just following the time- >> honored pattern in the IETF. :-) >> >>> If the authors of that work are on this list I would be interested >>> to hear from them about that decision. In particular, would just >>> having more private algorithms change their thinking or is >>> something else needed? >> >> They only needed one. This draft is for experimenters who need many >> at the same time. NIST has said that they are likely to later >> standardize on multiple post-quantum signature algorithms which will >> create larger payloads, and the DNSSEC community will have to decide >> if it wants just one of those, or many. Having a bit of experimental >> space for authoritative and recursive developers would be good, given >> that basically the entire range will be empty for centuries. >> >> --Paul Hoffman >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > -- > deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
