> 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]
