[cabfpub] Continuing the discussion on CAA

[Jacob Hoffman-Andrews]

On Mon, Oct 17, 2016 at 11:11 AM, Rick Andrews via Public <
public at cabforum.org> wrote:

> Posting to public list (seems to have been dropped)
>
> I'll need to poll folks internally, but Symantec would probably support
> this.
> How do other CAs feel?
>
> -Rick
>
> -----Original Message-----
> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> Sent: Monday, October 17, 2016 7:41 AM
> To: Gervase Markham <gerv at mozilla.org>; Bruce Morton
> <Bruce.Morton at entrust.com>; Ryan Sleevi <sleevi at google.com>; Rick Andrews
> <Rick_Andrews at symantec.com>
> Subject: RE: [cabfpub] Continuing the discussion on CAA
>
> I'd support a position if CAA was a validation check rather than an
> issuance
> check. That way there isn't a difference between "enterprise" and "retail".
> Instead, it's tied to the domain validation process and is required
> whenever
> domain validation is required.
>

Let's Encrypt checks CAA at validation time rather than issuance time,
because DNS checks are slow and unreliable. Doing the check at validation
time allowed us to consolidate the external-facing parts of our process
into a single component, and monitor the performance of that component with
the knowledge that it is affected by factors outside our control.

So, we also have a preference for checking CAA at validation time.

Regarding Gervase's comment about where in the process to do a high-risk
domain check: Let's Encrypt does a high-risk domain check against a static
list both at validation time and at issuance time, because it is very cheap
to do.

Hard vs soft CAA enforcement: Let's Encrypt doesn't allow human override
when we find a CAA record that forbids issuance. The number of support
requests we get due to incorrect CAA records is vanishingly small, though I
acknowledge that providers with a different customer mix might get
different results.

DNS fail open or closed: Let's Encrypt currently treats a SERVFAIL when
looking up CAA as "no CAA record present, okay to issue." However, we are
working to change this, so a CAA SERVFAIL will prevent issuance. In our
investigations we've found that 0.1% of domains with a current Let's
Encrypt certificate return SERVFAIL for CAA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161018/2cd95b61/attachment-0003.html>