I think there’s value in publicly logging things even if that isn’t the basis for trust. So I disagree that what I wrote boils down to what I didn’t write.
-Tim From: Ryan Sleevi [mailto:[email protected]] Sent: Thursday, November 30, 2017 1:57 PM To: Tim Hollebeek <[email protected]> Cc: Ben Laurie <[email protected]>; Paul Wouters <[email protected]>; [email protected]; [email protected]; Jeremy Rowley <[email protected]> Subject: Re: Anomalous Certificate Issuances based on historic CAA records On Thu, Nov 30, 2017 at 3:12 PM, Tim Hollebeek via dev-security-policy <[email protected] <mailto:[email protected]> > wrote: The problem DNSSEC checks for CAA was intended to solve was the fact that it is certainly possible that a well-resourced attacker can manipulate the DNS responses that the CA sees as part of its CAA checks. A better mitigation, perhaps, is for multiple parties to publicly attest in a verifiable way as to what the state of DNS was at/near the time of issuance with respect to the relevant CAA records. This leads to the idea that perhaps it's worth exploring enhancing existing CT logging servers to do CAA checks and log what they see. That's probably easier than setting up an entirely separate infrastructure for CAA transparency. CT servers could even communicate back to CAs the results they see to assist in detecting and identifying both malicious and non-malicious discrepancies between the CA's own checks and what the CT log is seeing. "Thanks for the pre-cert. We see a CAA record at X.Y.Z.Z.Y that doesn't include you. Do you really want to issue?" There are legitimate concerns that giving even more work to CT log servers might put even more burden and expense onto those who are running CT log servers, but that can probably be figured out. While I understand the intent of the suggestion, it basically boils down to: - To solve independently verifying CAA, we need Trusted Third Parties - We have CT logs (which are not meant to be TTPs) - We should make logs TTPs so we don't have to spin up new TTP infrastructure The goal of CT from the get go has been that logs do not need to be TTPs, and that this is achieved by the cryptographic properties of the design combined with the ecosystem mitigations to detect any deviance. This is not possible with a CAA-in-CT, because CT is fundamentally not designed to provide cryptographic attestations about the statement of CAA (if we had such attestations, the CA could provide them anyways). So I don't think we can get away from the notion that if we want CAA to be an independently-verified aspect, then you need either TTPs (and CT logs are by design not TTPs, and should not be made TTPs) or you need to solve the cryptographic verifiability (in which case, you don't need CT logs to do this). Of course, I think this is all conditioned on whether CAA's value is somehow tied to the independently-verified. I don't believe that it is, no more than we're requiring cryptographic proofs of CA's validation of OV/EV documents or chains of custody from the QGIS and QIIS' used to validate that data. Instead, CAA serves as a machine-readable expression of policy intent, no different than having http://domain.com/.well-known/caa in some machine readable form. Our primary benefit of having it expressed in DNS (versus that HTTP-based file) is that we can leverage DNSSEC as a bootstrap for trust when it's available (despite all of its warts - and cryptographic issues) and it more easily aligns with CA's existing practices of DNS-based validation. It may be surprising to hear me suggesting that we expect something of CAs without having it independently verified - but I think there's substantial value to be afforded applicants/subscribers, and I'm deeply worried when the suggestions we have to date are to introduce more TTPs, make explicitly non-TTPs into TTPs, or to add unreliable reporting mechanisms that might otherwise drive up the costs of a sensible risk mitigation technology. I think for those that want to serve in a CAA Auditor role have the iodef mechanism as a way of reporting potential strangeness in such a way that the burden shifts to the applicant, but also that their ability to recognize (or reject) such information is the most scalable solution.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
