[cabfpub] Continuing the discussion on CAA

[Phillip Hallam-Baker]

I concur with a few quibbles.

Given the use of DNS for domain validation, an attacker who can successfully spoof DNS can apply for a cert from the authorized CA. The ability to get a bogus cert from the CA of their choice does increase the attack surface but not by a huge amount.

DNSSEC may improve things or it may not. If DNSSEC is in place then it can be used to lock down DV as well as CAA. But that doth not necessarily make the system secure. The security of DNSSEC depends on the security of DNS registrars and it is not clear that these people understand the issues. 

[Right now, my private Web sites are all off line because the hosting provider has made an unauthorized change to the config and done so incompetently.]


I have maintained from the start that CAs can choose to implement strict CAA checking now or wait until it becomes a requirement. Unless of course you happen to be the CA that is the cause of CAA becoming a mandatory requirement in which case you might not have any need to implement anything ever at all.


> On Sep 9, 2016, at 3:41 PM, Gervase Markham <gerv at mozilla.org> wrote:
> 
> Everything Ryan says seems to make sense to me, except I have a further
> comment here:
> 
> On 08/09/16 23:34, Ryan Sleevi wrote:
>> #3 is clearly a sticking point. I think we're all pretty aware of CAs'
>> objections to this, but I do feel strongly that, without this, CAA is
>> not an effective security mitigation. As you know, Google holds a
>> variety of domains, and we routinely receive requests from other CAs
>> attempting to confirm that an applicant was duly authorized to make a
>> request, and we routinely have to contact CAs and request revocation for
>> certificates that were not authorized according to our company policy.
>> Allowing escape clauses, even at the EVGL level, significantly weaken
>> our ability to proactively prevent this, which we believe would reduce
>> both ours and CAs' administrative burdens.
> 
> This seems to be sort of a question of whether CAA is actually like HPKP
> ("deny access, come what may, if things get configured wrong") or more
> like an expired cert is currently treated in browsers ("allow an
> override with a warning/extra care").
> 
> As I see it, we have three options:
> 
> 1) Strict is the only way to go - Ryan's preference.
> 2) Loose(r) is the only way to go - let's pick one of Rick's 4 options.
> 3) Allow domain owner to decide, with loose(r) as default.
> 
> There may be better extension mechanisms than this in CAA, but 3) could
> be achieved by adding a CAB Forum-defined domain ("strict.cabforum.org")
> to the CAA record. If a CA sees this, they may not under any
> circumstances issue the certificate until they see the CAA record
> change, and to do so is a misissuance. If they don't see it, we use the
> High Risk process, or some EV process, or whichever of Rick's options we
> decide. I don't think this is much extra complexity - if we are going to
> require CAA checking, we can require CAA checking and
> strict.cabforum.org recognition too.
> 
> I suggest this because I think it might be a good way to meet Google's
> needs for absolute bans, without making CAA, like HPKP, a technology
> that only large sites will deploy because of the near-"bricking" potential.
> 
> I agree with Ryan that, even if the process is loose, we need proper
> audit trails to make sure the CA does the checks and follows the
> exception process properly.
> 
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160909/1d25a2e3/attachment.html