Referring only to the question of what was this at last call - -03 was WG and IESG reviewed. Doing a diff between this -09 and -03 seems to indicates as much text in the body was changed as was left intact.
Mike On Mon, Aug 4, 2025 at 07:03 Philip Homburg <[email protected]> wrote: > > Please note that this > > draft is already in the RFC Editor's queue, after having gone > > through WG Last Call, IETF Last Call, and IESG review. > > > > Making changes after it has been approved would likely bring the > > document back to (at least) the WG for review, which seems like a > > bad idea. If there are no technical errors, leaving the document > > as-is will get it published and implemented sooner. > > Does this draft still say what it said during WG last call? I read earlier > versions that seemed fine, but the last version seems quite strange to me. > > It says "Because of RSASHA1 and RSASHA1-NSEC3-SHA1's non-zero use, deployed > validating resolvers MAY be configured to continue to validate RRSIG > records > that use these algorithms" > > That is good. > > But earlier in Section 2 is says: "The RSASHA1 [RFC4034] and > RSASHA1-NSEC3-SHA1 [RFC5155] algorithms MUST NOT be used when creating DS > records. Validating resolvers MUST treat RSASHA1 and RSASHA1-NSEC3-SHA1 DS > records as insecure." > > This problematic for three reasons: > 1) It contradicts the later text that validating resolver MAY be > configured to > continue to validate RRSIG records that use these algorithms. > > So the drafts contradicts itself. > > 2) Disallowing new DS records from RSASHA1* prevents KSK rolls. It sounds > like a bad idea to disallow KSK rolls for an algorithm that is in > active use. > > 3) Some registries require the user to submit DNSKEY records and generate > DS > records themselves. A naive implementation of this at the registry > may prevent zones signing with RSASHA1* from performing an algorithm > roll > because it would require generating a DS RRset that includes a DS record > for RSASHA1*. > > What I think was meant was that the use of SHA1 in a DS record to generate > a > hash of the DNSKEY was deprecated. > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
