On Tue, 22 May 2018, Ryan Sleevi wrote:
I know of 12400 512 bit RSA ZSK's in a total of about 6.5 million. And I
consider those to be an operational mistake.
http://tma.ifip.org/wordpress/wp-content/uploads/2017/06/tma2017_paper58.pdf
has some fairly damning empirical data about the reliability of those
records, which is not in line with your anecdata.
My "anecdata" is Viktor Dukhovni's constant monitoring of all known
DNSSEC zones. It's data is current to a few days. The article you
quote used data up to Jan 2017, so is 1.5 years old. Still, it only
listed 275k out of 7M ZSK's being 512 bit RSA. I suspect it to be
due to one or a few providers who used to do that, but clearly no
longer do this since the current total is far lower at 12k out of
roughly the same sample size of 7M. Calling this data anecdata
isn't going to change anything other then my professional opinion
of you.
512 bit RSA keys was never a real thing in DNSSEC. I packaged up the
earliest versions of DNSSEC software for RHEL/CentOS/Fedora and it
never did anything less then 1024 for ZSKs, which was changed to 2048
bit on Mar 27 2014. KSK's were always 2048. I'm pretty sure the Debian
and Ubuntu packagers also didn't reduce the default upstream ZSK
keysizes to 512 bit.
But I'd love to read your research on where people advised you to roll
the ZSK at "24 - 72 hours" intervals. Do you have any links to
presentations given at any technology conference like DNS-OARC, RIPE,
IETF or ICANN?
I see no reason why not to log the entire chain to the root. The only
exception being maliciously long chains, which you can easilly cap
and error out on after following about 50 DS records?
"Why not" is not a very compelling argument, especially given the complexity
involved, and the return to value being low (and itself being inconsistent
with other matters)
CAs are in the business of verification, auditing and issuing security
certificates. If they cannot log why they made a certain decision in
the past based on the then gathered cryptographic material available,
they are simply not trustworthy at their job. Asking us to accept
"you should just trust we did the right DNSSEC checks in the past"
is pretty weak for a security institution, especially when you need
to resolve a dispute about a CAA record that was present at the time
but failed to prevent a certificate from being issued.
And if you cannot store a few kb of data per certificate (not) issued
based on a CAA record, then surely you're not mature enough to be in
the business of certifying and auditing anything.
Paul
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
