On Fri, Oct 14, 2016 at 1:49 PM, Gervase Markham via Public <
> On 14/10/16 18:32, Bruce Morton via Public wrote:
> > I think that the CA can limit risk by checking CAA records where there
> > has been no verified Enterprise RA or a Certificate Approver
> > established. In this condition, I think that the CAA record check should
> > be a hard fail.
> How would you code that, in practice? What would the UX look like for
> the validation specialist?
> Any version of this where CAA is not a hard-coded non-overrideable hard
> fail deprives CAs of the misissuance protection they could get when it
> is. Imagine if, even if an attacker got control of your entire infra he
> still couldn't issue for google.com, yahoo.com or other high profile
> sites because of CAA.
You could also say that any CA where domain control checks are not
"hard-coded non-overrideable hard fail" miss out on misissuance protection,
or really about any other technical checks on misissuance.
I don't think providing resistance to full compromise of a CA is what CAA
addresses. CAA is self-enforced, so it can address the threat of
misissuance caused by weaknesses in other *parts* of the CA's
infrastructure (like issuance protocols). SCT enforcement/auditing and HPKP
can provide some protection against *full* CA compromise, because they are
ultimately enforced by devices outside the CA's infrastructure.
In my experience, Bruce's description of organizations where the DNS team
isn't in effective coordination with the people requesting certs is
unfortunately common. How much weight that should have regarding CAA policy
is worth debating, but a debate on CAA should be oriented around a clear
threat model. It seems to me that CAA is valuable if it provides meaningful
technical controls that restrict issuance from the vast majority of CAs
with whom an organization will have no business relationship.
> That would make the consequences of the compromise
> significantly less bad for the internet, and therefore less bad for the
> CA. Protection against malicious misissuance (as opposed to an employee
> violating policy, say) is not the only benefit of CAA, but I think it's
> a useful one.
> Making mistakes with an organization's DNS can lead to all sorts of
> types of outage or disruption. Why is the disruption caused by a
> mistaken CAA record (which seems a fairly unlikely scenario to me, but
> let's run with it) so much worse that it needs specially protecting
> If an organization allows random employees to make unreviewed changes to
> its DNS, surely it has bigger problems than not being able to get certs?
> Public mailing list
Senior Advisor on Technology
Technology Transformation Service, GSA
Public mailing list