> On 30. Nov 2017, at 15:52, Ryan Sleevi <[email protected]> wrote: > >> On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy >> <[email protected]> wrote: >> Similar to the GlobalSign discussion, it is well possible that the domain >> briefly disabled their CAA records when you did the check — and re-enabled >> them later. >> > I think that, as CAA deployment becomes common, this pattern will be > not-uncommon. I would hope we don't sound false alarms when it does. >
Hi Ryan, thank you for your e-mail, I hear your concern. We did apply tight filtering before raising any cases, and urge any other evaluators to do so as well. We reported cases to CAs/this forum that seemed to hint at issues in CAA validation at CAs, such as the wildcard/nonwildcard mix. We also don’t see our reports as “alarms”, but as cases that might warrant a closer look. Domain records may change on short notice, and we carefully differentiated and analyzed each case. Consistently setting “issue ;”, for example, lets one expect that a domain will change that for issuance. Consistently reporting a set of CAs not including the issuing CA — not so much. If you have the capability to change CAA records at each issuance, why maintain a set of non-issuing CAs in your CAA records? Combined with configurations that can trigger corner cases (such as the wildcard/non-wildcard mix), we weighed these as worth reporting at that time. Having learned that the latter cases happen as well, we will be even more sceptical for these going forward. I honestly believe that we applied the maximum diligence that can be expected from an external evaluator, based on data that, depending on domain and time, was based on 8-hour or even 4-hour scan intervals *at issuance time*. Kind regards Quirin _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
