So it turns out DNSSEC solves CAA problems for almost nobody, because almost nobody uses DNSSEC. And given the serious flaws both in DNSSEC itself and exiting DNSSEC implementations, it is unlikely to be part of any solution to the current problems CAA is facing. The presence of DNSSEC in the BR policy for handling DNS failures, in hindsight, was probably a mistake, and certainly deserved a lot more scrutiny than it got (Gerv tossed it out as a possible compromise during CABF F2F discussion, and everyone sort of shrugged and put it in because it seemed reasonable at the time). Right now, the only thing it is really accomplishing is preventing certificate issuance to customers whose DNS infrastructure is flaky, misconfigured, or unreliable. Longer term, DNS over HTTPS is probably a more useful path forward than DNSSEC for CAA, but unfortunately that is still in it's infancy.
One of the things that has become very clear over the last year is that the idea that the idea that there is a single, globally coherent state for what DNS says at any particular time is more of a myth than a reality. I'm sure that most people familiar with DNS were already well aware of that, but it has been entertaining seeing that almost every possible DNS failure mode happens in practice with disturbing frequency. 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. Of course, to avoid some of the extremely interesting experiences the industry has had with CAA, any "improved" version of CAA needs to be much more clear about the proper handling of error conditions, discrepancies in DNS responses, handling of malformed CAA records, and so on. DNS is a complicated beast, and any specification that exclusively contains statements of the form "Let CAA(X) be the CAA record at DNS node X" is oversimplified to the point where implementing it in practice will cause problems. -Tim -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+tim.hollebeek=digicert.com@lists.mozilla .org] On Behalf Of Ben Laurie via dev-security-policy Sent: Wednesday, November 29, 2017 3:37 PM To: Paul Wouters <p...@nohats.ca> Cc: douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: Anomalous Certificate Issuances based on historic CAA records On 29 November 2017 at 22:33, Paul Wouters <p...@nohats.ca> wrote: > > > > On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > This whole conversation makes me wonder if CAA Transparency should > > be a thing. > > That is a very hard problem, especially for non-DNSSEC signed ones. > Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear chain of responsibility for keys, and that is relatively easy to build on. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
