On Fri, 8 Apr 2016, Evan Hunt wrote:
On this topic, I wasn't quick enough to get to the mic before the line was
closed, but I'd like to suggest a higher degree of caution with the "MUST
NOTs" and "MUST-'s" in the validator column, relative to the signer column.
I understand, and we don't want to break existing installations, but....
IIRC, RSAMD5 was originally mandatory to implement. I certainly don't mind
deprecating it for signing, but to tell validators that they not only don't
have to implement it, but actually MUST NOT do so, seems excessive. The
But we did not see much (any?) deployment of it. secspider shows just 19
of them. I will bet at least half of those are test domains.
http://secspider.verisignlabs.com/stats.html
only justiication I could see for that would be if MD5 were so
comprehensively broken that MD5-signed data could be trivially falsified,
and we're not there yet. IMHO it shouldn't go any lower than MAY.
Based on the above stats, I'd still prefer it to go away completely.
Similarly I think it's fine for {NSEC3,}RSASHA1 to get MUST- in the signer
column, but I don't see any near-term future where they should drop below
MUST in the validator column. It's still the default algorithm in the BIND
signer; it's going to be a long, long time before validators can start
ignoring it.
MUST- means you _must_ implement it, but it is expected to go to a lower
level in the future. The next revision of the doc could very well leave
it at MUST- if we don't see people moving to better algorithms. I'm
still somewhat optimistic that if popular signing software such as
opendnssec implements algorithm rollover, we might actually see many
migrations from RSASHA1{NSEC3} to RSASHA256.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
