I believe that Paul Wouters has made a compelling case regarding the current state of keying practices in DNSSEC deployment today. There is sufficient cryptographic rigor to merit logging this data for review of correct assessment as of the point in time at which certificate issuance decisioning was made.
I concur in full with the assertions and positions of Paul Wouters and Nick Lamb in the matters discussed in this thread up to this point. I believe CAA validation checks should incorporate the DNSSEC data where DNSSEC has been deployed. I believe the logs recorded by a CA should preserve that data which was relied upon in the issuance decisioning. I have some concerns pertaining to the state of logging as would appear to be alluded to by Jacob Hoffman-Andrews. Specifically, I find some cause for concern in the fragment "because it was not possible to associate specific query/response pairs with the validation request that caused them (for instance, consider NS referrals, CNAME indirection, and caching)". This would appear to indicate that while Let's Encrypt may log either the final response from their recursive resolver or some derivation of data from the final response from their recursive resolver, Let's Encrypt may not be logging _which_ particular entity within the DNS hierarchy they are utilizing as the controlling CAA record - or at least, this language suggests that for some circumstances they are not recording the underlying delegations/reasons for which a given CAA record somewhere in the DNS hierarchy was utilized when attempting to clear issuance for a given domain label. That becomes a bit concerning, as I would expect that a CA relying on a CAA record at " ok-sure.multiple-layers-of-indirection.my-crazy-dns-service.com" bearing tag "issue" with value "letsencrypt.org" when authorizing issuance of a certificate for dnsName "a.example.com" should be able to explain the chain of facts which made that CAA record at that position within the DNS hierarchy authoritative for the domain label in question. There arises a potential further concern if this logging of DNS data upon which a CA's decisions rely pertains to DNS queries for function beyond CAA clearance. For example, the DNS queries associated with domain control validation over a given domain label. Consider the software package acme-dns which assists domain holders with delegating the ACME dns-01 validation records onto a specialized DNS server which responds with the correct dynamic responses while allowing the underlying domain to have static delegations for the TXT records back in the actual authoritative zones of any number of domains that they don't want to migrate to dynamic DNS services. That's a great use case and should not be discouraged. Neither, however, should it the case that the CA's logging only has the response of the final result from the acme-dns server. The logs should contain the DNS query responses which connected that record served up by the acme-dns server to the delegation that granted that authority to the acme-dns server on behalf of the authorization domain name. On Wed, May 23, 2018 at 11:25 AM, Paul Wouters via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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/tma >> 2017_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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
