To fix this we need to extend DS to say that for any newly allocated digest types that they must include the matching DNS name for algorithm 253 and the match IOD for algorithm 254 before actual digest in the digest field. Then allocate PRIVATE SHA256, PRIVATE SHA-384 and PRIVATE GOST R 34.11-94 which are replacements for SHA256, SHA-384 and GOST R 34.11-94 respectively that support pre-publishing DS for PRIVATEDNS and PRIVATEOID.
> On 29 Mar 2022, at 08:08, Mark Andrews <ma...@isc.org> wrote: > > Note you can’t prepublish a DS to roll keys you need to publish the DNSKEY > first. > > -- > Mark Andrews > >> On 29 Mar 2022, at 05:33, Mark Andrews <ma...@isc.org> wrote: >> >> >> >>> On 29 Mar 2022, at 01:34, Paul Hoffman <paul.hoff...@icann.org> wrote: >>> >>>> On Mar 27, 2022, at 6:23 PM, Mark Andrews <ma...@isc.org> wrote: >>>> There is zero reason to reserve any ADDITIONAL space for experimentation. >>> >>> Assume that you want to experiment with creating responses that have >>> multiple as-yet-undefined algorithms. How would you do that today? >>> Differentiating in the RRdata, as is done today, would create a single >>> RRset in the response. >>> >>> --Paul Hoffman >>> >> >> You would add records of type 253 with “alg1.example.org” as the first >> algorithm name, “alg2.example.org” as the second algorithm name where >> example.org is a domain you control. If someone else is running another >> experiment they add 253 with the algorithm name specified as >> “alg1.example.net” where example.net is a domain they control. >> >> When you are checking if you support a particular instance of PRIVATEDNS you >> check the algorithm name as well as the algorithm number (253). >> >> For working out if the DS record indicates support for your PRIVATEDNS >> algorithm you need to find the matching DNSKEY based on the hash and extract >> the PRIVATEDNS algorithm name. If you can’t find a matching DNSKEY the >> DNSKEY RRset is bogus as the DS record says that the DNSKEY record exists. >> >> If you want to see how this would work add “PRIVATE-RSASHA256” using >> RSASHA256.ICANN.ORG as the first algorithm name and >> “PRIVATE-ECDSAP256SHA256” with ECDSAP256SHA256.ICANN.ORG as the second name >> as a starting point where they are reimplementations of RSASHA256 and >> ECDSAP256SHA256 respectively. Throw in “UNKNOWN.ICANN.ORG” with some random >> data as the rest of the key. >> >> About the only part not already specified is matching DS to DNSKEY using >> PRIVATEDNS but as you can see it is obvious to anyone with a little bit of >> cryptographic understanding. >> >> Mark >> -- >> 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 >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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 https://www.ietf.org/mailman/listinfo/dnsop
