On 28.3.2017 17:05, Evan Hunt wrote: > On Tue, Mar 28, 2017 at 03:36:40PM +0100, Tony Finch wrote: >> Chris Thompson just mentioned to me another reason for dropping support >> for RSAMD5: it uses a different DNSKEY tag calculation, which implies that >> dropping support should simplify validators more than dropping other >> algorithms. > > To be clear, for the benfit of those not in the room yesterday, I do *not* > object to deprecating RSAMD5, I agree with the "MUST NOT" in the signer > column, and that it's pointless to support it in new validator > implementations.
Thank you for clarification! > My problem is with elevating "pointless" to the force of a "MUST NOT". I > think it should be reduced in force to "OPTIONAL", "NOT RECOMMENDED", or > even "SHOULD NOT". Kill it on the supply side. Here I have to agree with enforcing "MUST NOT". MD5 is a risk even on the validating side. It might provide attacker with ability to forge TLSA records in zones signed with MD5, which is has much worse consequences than treating the zone as unsigned. It is a security nightmare because validators supporting MD5 will treat this as valid and happily accept forged certificates! IMHO validator going to insecure mode is the right thing to do. Applications are used to insecure records but there is no way to handle seemingly (but not factually) "secure" records. So again, MUST NOT is the right choice. I'm going to write tests for Knot Resolver to ensure we never set AD bit for zones signed using MD5. Right now. -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
