Dear Paul (and wg) I apologise for the tone. This went south quick and was due to my confrontational style of writing. The secspider-stats are indeed a good indicator, and convinced me that we shouldn’t make SHA1 related DNSKEY algorithms a "MUST NOT”.
In the spirit of being constructive, we (Jakob Schlyter, Matt Larson and I) have written a small draft (draft-arends-dnsop-dnssec-algorithm-update) that does two things: it changes RSASHA1 from “Must Implement” to “Recommended to Implement”. (RSASHA1 is the only “MUST IMPLEMENT”) it changes RSASHA256 from “Recommended to Implement” to “Must Implement”. The main motivator for this is that implementors have an incentive to move their implementations “default use” away from RSASHA1 (for instance, when a user generates a DNSKEY without specifying an algorithm, or when choosing an algorithm for signing in the presence of more than one algorithm. This is done in the style of RFC6944, which states that anything that updates the registry table must obsolete RFC6944 (not just update). Therefor, it is as minimal as possible, with no guidelines and no recommendations for the future. This is NOT a competing draft, though the titles look alike, and I do like to see advice and guidelines for developers and operators in a draft on the BCP track, not proposed standard. I’m looking forward to discuss this with the working group on the list and during the Chicago IETF DNSOP session. Warmly Sometimes Grumpy. (Roy Arends) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
